Pour que le scénario de fédération d’identité soit valide de bout en bout, il faut que l’application ait déclaré (via le fichier de configuration) que le STS (Security Token Service), à qui est délégué la gestion de l’authentification et de l’identité, est un STS de confiance (c’est à dire que l’application “croît” les informations renvoyées par ce STS), et il faut que le STS ait enregistré l’application comme Relying Party (c’est à dire que le STS accepte d’authentifier et de renvoyer les informations d’identité de l’utilisateur à l’application).
Ce double trust est essentiel puisqu’il permet au STS de ne pas gérer l’authentification d’applications non enregistrées (et donc de ne pas renvoyer de données d’identité à n’importe quelle application) et il permet à l’application de ne pas accepter les informations d’identité émit par n’importe quel STS.
Ce post explique comment enregistrer une application dans ADFS. Pour avoir les informations sur l’enregistrement d’une application dans ACS d’Azure, c’est ici : Enregistrer une application dans ACS.
Inscription d’une Relying Party
Pour démarrer l’inscription, lancez AD FS 2 Management. Sélectionnez le nœud Relying Party Trusts et cliquez sur l’action Add Relying Party.
Deux choix s’offrent à nous: enregistrer manuellement l’application ou utiliser le fichier FederationMetadata.xml généré par l’utilitaire Windows Identity Foundation Federation Utility (utiliser le fichier permet d’enregistrer automatiquement l’application à partir des informations saisies depuis l’utilitaire).
En choisissant l’enregistrement manuel, le premier écran de configuration demande un nom pour la Relying Party.
Le second écran permet de choisir si l’on souhaite utiliser le protocole SAML 2.0 ou SAML 1 / 1.1.
Il faut ensuite sélectionner un certificat si l’on souhaite encrypter le token renvoyé par ADFS.
L’écran suivant permet d’activer la fédération passive (par redirection vers le STS) et le SSO (Single-Sign-On). Pour faire de la fédération passive avec une application ASP.NET, il faut au minimum activer le protocole WS-Federation Passive et renseigner l’URL de l’application. Sans cette activation, la redirection qu’effectuera l’application vers l’ADFS sera refusée et un message d’erreur sera renvoyé.
L’écran suivant demande un nom unique pour la Relying Party (on peut laisser l’URL de l’application comme identifiant).
Le dernier écran, qui est disponible si on a utilisé l’enregistrement automatique, permet de configurer les autorisations par défaut des utilisateurs.
La Relying Party est configurée.
L’application peut maintenant effectuer la redirection vers l’ADFS pour demander une authentification de l’utilisateur.
Configuration des claims
Par défaut, ADFS ne va renvoyer aucun claim à une nouvelle Relying Party.
Pour configurer les claims renvoyés à l’application, sélectionnez la Relying Party puis cliquez sur Edit Claims Rules….
Sur l’écran d’édition des claims, vous aurez la possibilité d’ajouter/modifier et supprimer des règles.
Il y a 5 types de règles différentes :
- Send LDAP Attributes as Claims : renvoyer des attributs LDAP en tant que Claims
- Send Group Membership as a Claim : renvoyer un Claim en fonction de l’appartenance de l’utilisateur à un groupe AD
- Transform an Incoming Claim : transformer un Claim envoyé à l’ADFS (par les Identity Providers) et le renvoyer
- Pass Through or Filter an Incoming Claim : Renvoyer ou filtrer les claims envoyés à l’ADFS (par les Identity Providers)
- Send Claims Using a Custom Rule : Utiliser un Custom Attribute Store pour renvoyer des Claims (un _Custom Attribute Store _permet de récupérer des Claims à partir d’une source externe à l’ADFS, comme un web service métier)
Récupération des claims côté applicatif
Depuis l’application .NET, la liste des Claims est accessible depuis la propriété Claims de la classe ClaimsIdentity.
A bientôt !