Ne fournir que les infos nécessaires avec AD FS V2 | just disclaiming what is needed with AD FS V2
| Français | English |
| La deuxième loi de l’identité telle qu’on peut la trouver sur le site https://www.identityblog.com est “révélation minimale pour une utilisation contrainte”. Illustrons cela dans un scénario qui utilise Active Directory Federation Services (AD FS) V2 et Windows Identity Foundation (WIF). NB: les termes utilisés ici sont expliqués plus en détail dans le livre blanc téléchargeable ici L’exemple se base sur l’infrastructure suivante: | The second law of identity that one can find at https://www.identityblog.com is “Minimal Disclosure for a Constrained Use”. Let’s illustrate this with a scenario that leverages Active Directory Federation Services (AD FS) V2 and Windows Identity Foundation (WIF). NB: terms and definitiosn are available in the white paper (in French) that can be downloaded here. The sample uses the following architecture |
| un utilisateur dans le domaine bengui2.adatum.com se connecte à une application (relying party ou RP) qui est hébergée dans un autre domaine bengui1.contoso.com. Ces domaines sont dans deux forêts distinctes sans relations d’approbation Active Directory. L’utilisateur est connecté sur la machine BACAPP01. Le RP est hébergé sur la machine BCCAPP01. Le RP qui est sur la machine BCCAPP01 fait confiance au serveur AD FS V2 qui agit en tant que fournisseur de jetons (Secure Token Service ou STS) qui est installé sur BACDC01. En fait dans ce scénario, on a trois versions du RP: les applications fed1, fed2 et fed3. Une fois configuré, AD FS contient les informations suivantes: | A user in domain bengui2.adatum.com connects to an application (a relying party or RP) which resides in another domain bengui1.contoso.com. These domains are in two distinct forests with no Active Directory trust relationship. User is connected in machine BACAPP01. The RP resides in machine BCCAPP01. The RP that is installed in machine BCCAPP01 trusts the AD FS V2 server acting as a Secure Token Service (STS) which is installed on BACDC01. Actually, in this scenario, we have three versions of the RP: applications fed1, fed2 and fed3. Once configured, AD FS contains the following information: |
and
| l’application (RP) a besoin de savoir si l’utilisateur est un compte de test ou pas pour lui donner accès à certaines fonctionnalités. Le STS est configuré pour envoyer au RP fed1 une revendication de group avec une valeur constante de “testGroup” quand l’utilisateur appartient au groupe Active Directory BENGUI2\testgroup-all. Le STS enverra à fed2 des revendications de groupe pour chaque groupe Active Directory auquel le user appartient. Le STS enverra à fed3 une revendication de groupe correspondant au nom d’affichage de l’utilisateur tel que configuré dans Active Directory. Active Directory contient 2 comptes de test (test-a and test-b). test-a appartient à testgroup-A, test-b appartient à testgroup-B, et testgroup-all contient les deux groupes testgroup-A et testgroup-B. | The relying party needs to kow if the user is a test user or not in order to give him access to some features. The STS is configured to send to RP fed1 Group claims with a constant value of “testGroup” when user belongs to Active Directory BENGUI2\testgroup-all. STS will send to fed2 Group claims for each Active Directory group the user belongs to. STS will send to fed3 a Group claim with a value corresponding to Active Directory user’s display name. Active Directory contains 2 test users (test-a and test-b). test-a is a member of testgroup-A, test-b is a member of testgroup-B, and testgroup-all contains both groups testgroup-A and testgroup-B. |
| Le RP est une application WIF ASP.NET générée à partir du modèle suivant (elle est aussi configurée pour faire confiance au STS): | The RP is a default WIF ASP.NET application generated from the following template (it’s also configured to trust the STS): |
| Connectons-nous maintenant au RP depuis la machine BACAPP01 en utilisant trois comptes: administrator@bengui2.adatum.com (qui n’est pas un compte de test), test-a@bengui2.adatum.com et test-b@bengui2.adatum.com. NB: de façon à se voir demander le username et ne pas avoir à créer de nouvelle session Windows pour chaque compte, Internet Explorer est configuré pour toujours demander les informations de connexion: | Let’s now connect to the RP from BACAPP01 machine, using three users: administrator@bengui2.adatum.com (which is not a test user), test-a@bengui2.adatum.com and test-b@bengui2.adatum.com. NB: In order to be prompted for a username and avoid having to create a new Windows session for each user, Internet Explorer is configured to always ask for credentials: |
| NB: le compte administrator n’a pas de nom d’affichage | NB: administrator account has no display name: |
| Nous venons de voir qu’AD FS V2 permet d’émettre des revendications qui ne sont pas reliées directement au attributs Active Directory (NB: les attributs pourraient même être stockés en dehors d’Active Directory). En fonction des besoins du RP, ne dévoiler que le fait que l’utilisateur courant est un utilisateur de test ou pas comme avec fed1 peut être suffisant. L’authentification à base de revendications permet de mélanger authentification et autorisation. Dans certains cas, l’authentification peut même ne pas contenir d’identification précise de l’utlisateur; seuls les rôles sont passés au RP. | We just saw that AD FS V2 allows to issue claims that are not directly related to Active Directory’s attributes (NB: attributes could even be stored outside Active Directory). Depending on the RP needs, disclosing only the fact that current user is a test user or not like with fed1 may be sufficient. Claims aware authentication allows to mix authentication and authorization. In some cases, authentication does not even contain any specific identification of the user; only roles can be passed to the RP. |