C’est reparti pour quelques sessions de blogging intensif : comme chaque année, je suis aux TechDays Microsoft, et je vais vous faire partager mes notes sur les sessions que j’irai voir. On commence par cette session à l’intitulé long, mais pourtant pas explicite. J’espère ne pas m’être trompé en venant y chercher des informations sur comment fédérer des identités dans des environnements hétérogènes. D’après ce que j’ai lu, il me semble que les revendications dont il est question sont un moyen technique correspondant aux “claims”, à savoir la présentation des droits requis par le client, et la validation de ce “claim” par le serveur en comparant ceci à son propre contexte, et en demandant au besoin la confirmation par un serveur tiers. On verra…
Introduction
La session est présentée par Philippe Beraud, Benjamin Guinebertière (un co-auteur dans le dernier Programmez! si je me rappelle bien) et Stéphane Goudeau, tous trois architectes à Microsoft France. Dommage qu’il n’y ait pas un intervenant extérieur : ça apporte souvent beaucoup de clairvoyance dans une session.
Le but de la session telle que présenté par P.B. est de montrer quelques architectures de référence sur la fédération d’identité, qui a maintenant plusieurs années derrière elle, avec des standards à peu près reconnus désormais.
Les technos Microsoft derrière la fédération d’identité sont Active Directory Federation Services 2.0, Windows Identity Foundation 1.0 et Azure AppFabric Access Control Services 2. Ce dernier supporte la fédération des identités de réseaux sociaux. La session n’est pas technique sur ces produits, mais montre plutôt comment ils peuvent être utilisés dans des scénarios standards.
Revendication est bien la traduction adoptée par Microsoft France pour la notion de Claim-Based Identity. On parlera de WebSSO, voire de WebSSO fédéré, y compris avec des services web sur lequel on tape en interne ou dans un domaine externe.
Les orateurs recommandent pour une approche plus théorique le “Guide to Claims-Based Identity and Access Controls” dans la collection Patterns and Practices de Microsoft.
Oasis a créé un standard WS-Federation. Il y en a d’autres, mais le modèle de base est une triplette entre Identity Provider, Resource et Requester. Mais il y a bien sûr de nombreuses architectures potentielles pour mettre ceci en place. Ce type de modèle existe depuis AD : un ticket Kerberos fourni par le serveur de domaine est fourni par le client à un serveur qui fait confiance au domaine, et accepte donc le client. On est clairement dans le schéma standard. Le jeton est appelé le TGS. Ce schéma fonctionne bien avec toutes les applications Kerberos, et depuis une dernière version, il y a possibilité de déléguer la contrainte Kerberos, en demandant à un serveur web distant de réclamer une identification Kerberos. Par contre, ce mode est limité, car enfermé dans la forêt AD. Du coup, ça ne passe pas sur le Cloud, sur des applications Kerberos, sur des domaines étrangers…
Bref, il fallait quelque chose de supplémentaire. L’idée de l’authentification fédérée est de remplacer le serveur Kerberos par un service de jeton de sécurité (STS), avec lequel les serveurs de ressources vont établir également un cadre de confiance, et le client récupérer un jeton, la différence étant uniquement au niveau du contenu du jeton : les protocoles et contenus sont différents, mais la cinématique est toujours exactement la même. Par contre, un STS va pouvoir valider un jeton, en prendre un pour en émettre un second sous une forme différente, de façon à être agnostique par rapport au format du jeton.
Nous abordons ensuite des scénarios d’utilisation :
Fournisseur d’identité interne
Le service de jeton est simplement connecté à l’annuaire. Il y a des nouveaux projets Visual Studio notés comme “Claims-Aware”. L’exemple est fait sur un site web pour être plus visuel qu’avec un service.
Au niveau des références, on voit Microsoft.IdentityModel, ce qui correspond à WIF. Ensuite, on ajoute une “Référence STS”, de la même manière qu’on ajoute par exemple une référence web. Le fichier de configuration est modifié pour charger les librairies nécessaires, et un certificat par défaut a été créé.
On voit du coup bien le site web ainsi que le site web créé pour STS, qui contient une page de login, sur laquelle le site web d’origine redirige. La tringlerie est donc bien cachée, et on peut modifier le code par défaut avec les API de sécurité pour rajouter des rôles, etc. Si on avait besoin de partager la sécurité avec un site web complètement extérieur, il suffirait alors de pointer l’autre site web sur le STS qui a été créé par défaut avec la première.
La question qui se pose alors est de savoir qu’est-ce qu’on met dans le jeton STS : on met des données applicatives, mais aussi des applications liées à l’entreprise. L’important étant bien sûr de ne pas trop faire grossir le jeton. Donc, typiquement un numéro de matricule, mais surtout pas les détails complets de l’utilisateur. Si on en a besoin, on se servira du contenu pour aller chercher dans des référentiels externes les données supplémentaires nécessaire, application par application.
Ce scenario reposait sur WS-Federation. ADFS est par contre capable de faire en plus de la transition de fédération entre du WS-Federation et du SAML 2.0, et ce dans les deux sens. Cette transition de protocoles supporte d’ailleurs d’autres méthodes. ADFS a également un intérêt en termes de configuration fine des autorisations de création de jetons.
Le sous-scénario suivant utilise justement ADFS comme STS. On voit alors la feuille de redirection proposer plusieurs modes d’authentification, puis IE affichant la nouvelle boîte de login, telle que celle lorsqu’on souhaite enregistrer son MDP sur le client TSE en Windows 7. Les groupes AD sont transformés en rôles de sécurité par une règle. Une autre règle, par exemple, associe l’adresse e-mail extraite du LDAP d’AD à un attribut supplémentaire du token.
Pour la mobilité, ADFS peut être exposé sous forme d’un proxy, qui aura une gestion de sécurité périmétrique différente. La communication entre ADFS et son proxy est chiffrée par certificats partagés.
STS-Resource
L’idée du STS-Resource est que le cadre de confiance du serveur n’a pas à être lié au STS qui est potentiellement plus proche du client, mais à un STS correspondant qui est plutôt dans son domaine. Le STS-Resource va émettre des données spécifiquement applicatives qu’il rajoute au token reçu et qui ne comportait que de l’identité.
On peut chaîner les STS-Resource, et même utiliser un STS-Resource qui se trouve dans un domaine Azure. La démo montre un SharePoint qui donne le choix entre l’authentification AD, et un STS à lui. On choisit cette deuxième possibilité, et on arrive ensuite à la page STS montrant les différents modes d’authentification. Bref, on a bien vu le relai opéré…
Fédération avec des partenaires
Le problème avec l’authentification partagée avec des partenaires est que si on traite au niveau applicatif, on est obligé de supporter tous les formats de tous les partenaires. ADFS peut alors être plutôt utilisé pour fédérer les partenariats, et réaliser de manière transparente la transformation de format.
Par contre, il faut alors que le ADFS soit capable d’aller retrouver les fournisseurs d’identités vers lesquelles elle peut avoir de la confiance. Une façon relativement simple de faire peut être de demander l’adresse email, et se servir du nom de domaine après le signe @ pour retrouver le serveur auquel on demandera de valider le token envoyé en claim.
L’exemple montré est de se rediriger vers la page Shibboleth du réseau Renater pour se connecter en retour sur un SharePoint.
Logiciel en tant que service
Conceptuellement, on est proche du scénario précédent, mais pour avoir une approche multi-tenant, il va falloir être le plus intégré possible avec les systèmes d’identité. La vraie difficulté est que seules des entreprises de taille suffisante pourront avoir un STS pour être fournisseur d’identité à destination d’une application Cloud. Pour les petites structures, l’idée peut être d’avoir un fournisseur d’identité dédié sur le Cloud.
Mais une autre approche peut être de faire confiance à des services comme ACS pour établir le cadre de confiance entre ADFS et des fournisseurs d’identités de réseau sociaux dans le nuage. Par exemple, on peut chaîner le STS sur un relai GoogleID, ou Facebook.
www.fabrikamshipping.com est une application de démo de ces modes de fonctionnement.
Solutions pour le Cloud
Sur le Cloud, le problème n’est pas sur la fédération, relativement bien maîtrisée, mais plutôt sur la présence de serveurs relais.
En démo, on déclare un domaine de confiance d’entreprise sur un site web envoyé sur le Cloud. On peut bien sûr optimiser les échanges, en faisant en sorte qu’une personne authentifié sur le domaine AD utilisé passe directement sur le site web dans le cloud.
WS-Trust, OpenID, WS-Federation sont supportés par ACS, qui est l’équivalent de ADFS mais sur le Cloud. En seconde démo, on passe donc par ACS, qui délègue à OpenID. Lui-même, qui se trouve dans le Cloud, avait été délégué par l’ADFS de l’entreprise pour accéder à une application dans le Cloud. On voit bien le chaînage dont on nous parlait au début de la session.
Sur ACS, on peut utiliser une interface web pour sélectionner les types d’authentification internet auxquelles on fait confiance.
La dernière démo se fait en utilisant une authentification Facebook sur téléphone mobile. Plus visuel, mais les concepts étaient bien les plus importants : le relai d’authentification, la transformation de protocole, et la capacité à réaliser ceci de manière automatique sur le Cloud.
Conclusion
Le passage vers des technologies sur Claims devrait se faire relativement en douceur. Les démos ont effectivement bien montré ce point : l’identité est facilement portable, en augmentant les cadres de confiance avec des partenaires.
http://tinyurl.com/claimsguide pour le guide Microsoft.
