Nouvelles Chroniques d'Amethyste

Penser au Sens, pas au Verbe

Mettre en place l’authentification avec Visual Studio 2013 partie II

Poster un commentaire

Nous allons poursuivre l’exploration des templates Visual Studio d’authentification dans nos projets entamée ici:

https://amethyste16.wordpress.com/2014/07/04/mettre-en-place-lauthentification-avec-visual-studio-2013-partie-i/

Pour rappel il s’agit d’explorer ce formulaire:

2014-08-17_11-09-57

Ces options permettent d’accéder au tout nouveau Framework ASP.NET Identity qui, rappelons le, est basé sur un pipeline OWIN. C’est cela que l’on doit utiliser à la place des anciens frameworks dans toute nouvelle application. Si vous avez besoin d’un tour d’horizon:

https://amethyste16.wordpress.com/2014/08/15/lauthentification-en-asp-net-un-tour-dhorizon/

 

Nous avons détaillé l’option « Individual User Account« , il ne reste plus qu’à explorer « Organizational Accounts« .

Le choix de cette option laisse apparaître un menu assez complexe:

2014-08-17_11-09-57

La première liste déroulante propose 3 options pour choisir son AD:

  1. Cloud – Single Organization
    On souhaite se connecter à notre propre Azure AD
  2. Cloud – Multiple Organizations
    L’application devra accepter des utilisateurs de plusieurs tenants Azure AD
  3. On premises
    On ne souhaite pas utiliser Microsoft Azure Directory. On utilisera ADFS

 

Cette fois nous allons utiliser les service WAAD pour les deux premières options et ADFS pour la dernière option. Si vous avez besoin de découvrir un peu WAAD:

https://amethyste16.wordpress.com/2014/08/21/decouverte-de-windows-azure-active-directory-waad/

 

La liste déroulante Access Level propose quand à elle:

  1. Single Sign On
  2. Single Sign On, Read Directory Data
  3. Single Sign On, Read and Write Directory Data

Cette liste n’est pas disponible si on choisit un AD « on premises ». Elle détermine les droits accordée à Graph API sur le tenant. Read signifie que l’on pourra lire les informations de profil, Write que l’on pourra les modifier. Single Sign On signifie juste que l’on peut se loguer.

 

Explorons les différentes options de ce formulaire. Les deux premières supposent que l’on dispose d’un tenant WAAD (un directory Azure AD):

https://amethyste16.wordpress.com/2014/08/19/provisionner-un-repertoire-azure-active-directory-waad/

 

Nous aurons besoin également d’une base SQL Azure pour le déploiement. Celle-ci pourra également servir à enregistrer des informations supplémentaires au sujet des utilisateurs par l’application Web.

  • Nom: Amethyste_db
  • Serveur: tcp:oi8yrm04ov.database.windows.net,1433

Note: n’oubliez pas  d’activer les services:

2014-08-21_20-40-07

Cloud – Single Organization

Créons une application Web ASP.NET. Une fois parvenu sur ce formulaire:

2014-07-03_22-14-57

Sélectionnez Change Authentication pour arriver ici:

2014-08-17_11-09-57

Choisir Organizational Account puis Cloud – Single Organization.

Notre tenant est toujours sous le nom de domaine par défaut: amethysteTest.onmicrosoft.com.

Donc:

2014-08-21_11-23-38

  • Faire OK. Une page de login devrait s’ouvrir si vous n’êtes pas connecté au tenant. On se logue avec un des comptes créé dans le tenant Azure (il doit avoir le rôle Global Administrator car il doit accéder à Graph API en notre nom).

On fait OK à nouveau une fois terminé et laisse l’assistant construire le template de l’application.

  •  Lancez l’application

On se voit proposer un formulaire de demande d’authentification:

2014-08-21_11-41-39

On sélectionne toto1:

2014-08-21_11-43-55

Puisque l’on a sélectionné Read  Directory, un click sur le logon affiche le profil:

2014-08-21_12-24-58

 

Notez au passage que l’url n’est pas celle de l’application. On est donc bien dans le cadre d’Azure AD. On peut d’ailleurs le démontrer autrement:

Rendez vous dans le portail Azure et bloquez toto1 depuis le profil du compte et faite SAVE:

2014-08-21_11-47-49

Déconnectez-vous puis reconnectez vous. Cette fois:

2014-08-21_11-49-02

Ok, ça marche en local, mais que se passe t’il si je souhaite déployer l’application?

Il est alors nécessaire de déclarer notre application dans le tenant Azure afin d’activer le SSO. On peut le faire depuis le portail, mais dans le cadre de ce tutoriel on va le faire au déploiement.

 

  • Lancez la commande PUBLISH

Une fois parvenu à ce formulaire:

2014-08-21_20-30-35

 

  •  Cochez Enable Organizational Organization et renseignez les options
  • Insérez la chaîne de connexion vers votre base de données dans le champ TenantDbContext
  • Faites Publish

Au bout d’un moment l’application démarre. Vous n’avez plus qu’à vous loguer pour accéder à l’application.

 

Si on se rend sur le portail, on devrait trouver une situation similaire à celle-ci:

2014-08-21_13-09-15

La première ligne est la déclaration faite par l’assistant de déploiement. La deuxième est celle faite par Visual Studio lorsque l’on a lancé l’application à des fins de tests.

  • Cliquez pour voir le détails des connexions:

2014-08-23_00-12-51

 

  • Repérez la barre des menus:

2014-08-23_00-15-43

  • Cliquez sur le menu Manage access:

2014-08-23_00-17-07

 

On peut révoquer les droits qu’ont les utilisateurs du tenant de se connecter à l’application.

2014-08-23_00-22-56

L’application n’est ensuite plus affichée dans la liste des applications enregistrées.

Cloud – Multiple Organizations

Vous avez publié une application en mode Saas sur Azure. Ce type d’application est en général multi-tenant, c’est à dire que vous souhaitez que les clients de cette application puissent se connecter depuis leur propre AD. Ce scénario n’est pas envisageable dans le cas précédent puisqu’il attend un compte issu du tenant que vous avez provisionné dans votre abonnement.

Azure AD fournit un support pour les applications multi-tenant, c’est justement l’objet de la deuxième option de notre formulaire.

Le client aura juste besoin de créer un tenant Azure AD dans son abonnement et le synchroniser avec son AD. La suite de la procédure est détaillée ci-après:

 

Configuration de test

Pour la suite on devra disposer de deux abonnements S1 et S2 chacun avec un tenant. l’application est déployée dans S1 et S2 sera notre tenant de tests. Nous avons testé la suite avec les paramétrages suivants:

Azure AD S2

  • Domaine: domaineS2.onmicrosoft.com
  • Global administrator: adminS2
  • User: userS2

Azure AD S1 (celui-où on déploie l’appli)

  • Domaine: domaineS1.onmicrosoft.com
  • Global administrator: adminS1
  • User: userS1

 

Démonstration du scénario

La procédure est très similaire à celle du cas précédent. On renseigne la même chose, on déploie de la même façon. Intéressons nous aux différences:

2014-08-22_19-39-49

Une fois déployée si vous vous rendez sur le portail Azure vous devriez voir ceci après avoir sélectionné le tenant puis l’application nouvellement installée dans l’onglet APPLICATION:

2014-08-22_19-43-40

Dans les anciennes versions du portail on trouvait aussi une zone de saisie appelée Url for granting access. Elle n’est plus disponible,  on trouvera de nouvelles informations ici (Building the link that grants access for external users)

http://msdn.microsoft.com/library/azure/dn132599.aspx#BKMK_MultiT

 

Important: Fermez toutes les instances de navigateur pour éviter les interférences entre les essais que l’on va faire et d’autres sessions web.

 

Si on lance l’application, on constatera que cette fois on n’est pas immédiatement redirigé vers le formulaire d’authentification, mais sur la page d’accueil. On remarque que la barre des menus a changée:

2014-08-22_22-24-01

Sign in est le menu que nous avons l’habitude de trouver, on trouvera par exemple:

2014-08-21_11-41-39

Intéressons nous à Sign up for this application.

2014-08-22_22-29-20

  • Cliquez sur Sign up

Le clic sur Sign up nous demande de nous authentifier. On utilise le compte userS2@domaines2.onmicrosoft.com. Ce compte n’est pas administrateur il s’affiche alors:

2014-08-23_22-16-31

  • Cliquer sur Envoyer demande

2014-08-23_22-17-02

Notre valeureux administrateur reçoit le mail suivant:

2014-08-23_22-17-44

  • Cliquer sur le lien

2014-08-23_22-19-13

 

  • On se connecte et:

2014-08-23_22-19-33

Si on s’était connecté avec un compte admin on serai arrivé directement là.

Note: Le logo (en bleu) peut être modifié dans le portail s’il ne vous plait pas et je pense qu’il ne vous plait pas!
Plus sérieusement, le logo fournit un moyen simple d’identifier l’organisation pour laquelle on donne un accès.

 

  • Cliquez sur accorder l’accès

2014-08-22_22-57-19

 

L’administrateur devrait recevoir un mail de confirmation:

2014-08-23_00-43-34

Normalement l’application devrait se lancer.

2014-08-23_22-20-37

 

  • Allons maintenant dans S2/Active Directory et regardons les applications du tenant de test:

2014-08-23_00-08-53

L’application est enregistrée dans le tenant. Tous les utilisateurs de ce tenant peuvent se connecter à l’application.

 

Le déploiement s’effectue dans les même conditions que dans le cas précédent.

 

On premises

La dernière option de notre formulaire, mais je n’ai pas la possibilité de la tester.

Cette option peut éventuellement être remplacée par Windows Authentication.

 

2014-08-23_23-10-42

Le document contenant les méta données vous sera fournit par votre admin.

 

Conclusions

Voilà, cet article clôt la série sur Visual Studio et les scénarios standards. Bien entendu il y a encore pas mal de choses à faire. Nous ne nous sommes pas penché sur le code par exemple, nous n’avons pas mis en place de provider de SSO personnalisé ni de de scénarios d’authentification double facteur qui est de plus en plus à la mode. Que se passe t’il si le client est une application desktop par exemple, comment migrer depuis une application existante vers ASP.NET Identity. Il serait également intéressant de parler de OAuth, de CAS…

Bref pas mal de sujets en perspective pour  de futurs articles. En attendant lisez les articles cités dans la bibliographie.

 

 Bibliographie

 

 

Publicités

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s