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 ACS d’Azure. Pour avoir les informations sur l’enregistrement d’une application dans ADFS, c’est ici : Enregistrer une application dans ADFS.
Inscription d’une Relying Party
Pour démarrer l’inscription, connectez-vous à Access Control Service (l’URL est sous la forme https://<nom_acs>.accesscontrol.windows.net/) puis cliquez sur Relying Party applications.
Cliquez sur Add pour ajouter une Relying Party.
Après avoir renseigné le nom de la 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, il faut renseigner l’URL de l’application, l’URL de retour (utilisée par ACS pour envoyer le token à l’application) et une URL optionnelle de retour en cas d’erreur.
On a ensuite la possibilité de choisir entre le protocole SAML 2.0, SAML 1.1 ou SWT, de choisir si l’on souhaite encrypter le token renvoyé par ACS (uniquement si on a choisi l’option configuration manuelle) et de choisir la durée de validité du token.
La deuxième partie de l’écran permet de configurer l’authentification. On doit sélectionner les Identity Providers que l’on souhaite utiliser pour l’application. On a ensuite le choix entre créer un nouveau groupe de règles de génération de Claims ou réutiliser un groupe existant.
La dernière partie de l’écran permet de spécifier le certificat avec lequel le token sera signé.
Configuration des claims
Par défaut, ACS va créer un nouveau groupe de règles vide pour la Relying Party. Ce groupe va nous permettre de configurer les claims renvoyées par ACS à l’application et pourra être réutilisé par d’autres Relying Party.
Cliquez sur Rule groups sur le menu de gauche puis sélectionner le groupe de règle associé à notre Relying Party (si vous avez choisi l’option Create new rule group, un nouveau groupe portant le nom de la Relying Party sera créé).
ACS propose, via le bouton Generate, de générer des règles pré-définies pour les différents Identity Providers disponibles.
Il est possible d’ajouter manuellement une règle en cliquant sur Add. La première partie d’écran permet de définir quel claim envoyé à ACS de quel Identity Provider va être concerné par la règle (la configuration ci-dessous permet de créer une règle sur les claims de type nameidentifier envoyé par Windows Live ID).
La deuxième partir de l’écran permet de définir les transformations à effectuer sur le claim envoyé à ACS et quel claim sera renvoyé par ACS (la configuration ci-dessous permet de renvoyer à la Relying Party un claim de type name contenant la valeur du claim de type nameidentifier envoyé par Windows Live ID).
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 !