Azure AD – limiter l’accès à ton application à certains utilisateurs uniquement
Salut !
Tu sais probablement déjà configurer Azure Active Directory pour sécuriser l’accès à ton application. Si ce n’est pas le cas, je te suggère de consulter l’article de mon ami André Girard à l’adresse suivante : http://aproposdunuage.com/2017/12/14/comment-creer-un-nouvel-usager-dans-azuread/
Toutefois, tu te rendras compte que cette procédure te permet d’autoriser l’accès à ton application aux utilisateurs de ton répertoire Azure AD.
Cependant, dans certains cas, tu devras limiter cet accès à un nombre restreint d’utilisateurs. Par exemple, une application de gestion.
C’est là que le portail Azure AD va te venir en aide!
Ben là! Je peux créer des groupes et rendre l’application accessible uniquement à ces groupes!
Oui, mais à condition que tu utilises une souscription Azure AD Standard ou Premium… qui ne sont pas gratuites.
Pour connaitre les différences entre ces souscriptions et le détail de leurs tarifications, consultes cette page : https://azure.microsoft.com/fr-ca/pricing/details/active-directory/
Alors dans ce cas, je peux spécifier mes utilisateurs au sein de l’application
Oui, tu peux définir divers mécanismes pour spécifier les utilisateurs à autoriser dans l’application (directement dans le code; via un fichier XML; via une table dans une BD; etc.) mais globalement, il faudra que l’administrateur soit une personne qui a des connaissances en programmation pour pouvoir apporter les modifications à cette liste.
Ok. Comment Azure AD peut m’aider ?
Le scénario
Nous allons illustrer cela via un exemple :
Il semble que le Mark 47 fut la dernière itération de l’armure d’Iron Man (http://ironman.wikia.com/wiki/Mark_47). Mais ce qu’on ne sait pas, c’est que Tony Stark en développe une 48e, le « Mark 48 » ! Tony veut avoir accès à ses plans mais ne veut pas que Steve Rogers (le Captain America) y ait accès aussi, car ils sont en froid depuis leur altercation dans Civil War. Tony veut toutefois pouvoir compter sur Azure AD afin de pouvoir donner accès à ces plans à quelqu’un d’autre plus tard si nécessaire (à Pepper ou à Jarvis, par exemple).
Restreindre l’accès
Maintenant que tu es en contexte, voyons comment implémenter cela…
Pour commencer, il faut faire exactement comme tu le ferais d’habitude pour sécuriser l’accès à ton application via Azure AD (tu peux suivre les instructions de l’article d’André Girard).
Ce faisant, on remarque que Steve Rogers peut se connecter :
Le but est d’empêcher tout utilisateur, qui n’a pas été explicitement assigné à une application, de s’y connecter.
Pour cela, va dans la section « Entreprise applications » de la fonctionnalité « Azure Active Directory » et cliques sur « All applications ». Tu y verras l’application de Tony Stark « SecretPlansMark48 ». Elle apparait dans cette liste car au moins un utilisateur s’y est déjà connecté.
Cliques sur cette application puis va dans l’onglet « Properties » via le panneau latéral gauche. Là, actives l’option « User assignment required » (en d’autres termes, mets-là à « Yes ») puis cliques sur « Save ».
À présent, aucun utilisateur, à l’exception de ceux qui auront été assignés, ne pourra se connecter à l’application.
Assigner des utilisateurs à l’application
Pour assigner un nouvel utilisateur, il suffit d’aller dans l’onglet « Users and groups » et de cliquer sur « Add user ». Tu pourras ajouter un utilisateur de ton Azure AD ou encore inviter un utilisateur via son adresse courriel.
Révoquer l’assignation d’un utilisateur à l’application
Étant donné que Steve Rogers s’est préalablement connecté à l’application, il faut parti des utilisateurs assignés !
Pour lui révoquer son accès, il suffit d’aller dans l’onglet « Users and groups », de cocher son entrée, de cliquer sur « Remove » et enfin de cliquer « Yes » au message de confirmation qui s’affichera :
Et… action !
Maintenant que toutes les pièces du puzzle sont en place, faisons quelques essais.
Demandons à Tony Stark de se connecter. Sa tentative de connexion va réussir :
Demandons à présent à Steve Rogers de se connecter. Sa tentative de connexion va échouer :
Toutefois, tu remarques que l’affichage de l’échec de connexion n’est ni élégant, ni explicite… Certes, en examinant le message d’erreur de plus près, on voit que l’échec de connexion est dû à un accès refusé.
De plus, pour voir ce message d’erreur, il faut ajouter le code suivant dans le web.config de l’application Web :
https://gist.github.com/BelRarr/c75b24a8e59689b9f197c78c5b9483c0
Nous allons voir comment remédier à cela.
Avoir un affichage plus explicite de la raison de l’échec de connexion
La solution à cette problématique, je l’ai trouvée dans l’article suivant : https://samlman.wordpress.com/2015/04/10/how-to-fix-the-openid-access-denied-when-user-wont-grant-rights-at-login/
Je l’ai toutefois adaptée un peu :
- J’ai ajouté un contrôleur, une action et une vue vers laquelle l’utilisateur non autorisé sera redirigé;
- J’ai modifié le code décrit dans l’article ci-dessus pour rediriger vers cet emplacement. Ce code se trouve dans le fichier Startup.Auth.cs. En résumé, il s’agit d’ajouter ceci :
https://gist.github.com/BelRarr/de6789ba66c1b92690029ac4b4afc11b
Note : Tu peux obtenir la solution Visual Studio complète sur mon GitHub.
À présent, demandons à nouveau à Steve Rogers de se connecter. Sa tentative va encore échouer mais avec un message plus élégant cette fois-ci :
En conclusion…
La fonctionnalité qu’on a explorée aujourd’hui a pour but d’empêcher tout utilisateur, qui n’a pas été explicitement assigné à une application, de s’y connecter.
Cette fonctionnalité est un exemple supplémentaire que de plus en plus d’actions sur ton compte Azure peuvent être apportées à même le portail. Ainsi, un administrateur Azure n’a pas à se soucier de la technologie sous-jacente qui fait battre le cœur de l’application. Peu importe ce que cette technologie est, l’administration de l’application et de ses fonctionnalités se fera exactement de la même façon.
J’espère que cette nouvelle connaissance te sera utile.
Au plaisir de te revoir ! 🙂