Principe de fonctionnement de la fédération d’identités

identités. Un fournisseur de ressources offre et contrôle l’accès aux ressources du genre bases de données et fichiers.

La plupart des organisations combinent les deux : elles offrent des ressources à leurs organisations partenaires et émettent et gèrent les comptes de leurs propres employés. Dans le contexte de la fédération d’identités, les fournisseurs d’identités et de ressources sont parfois considérés comme des îles, un terme qui souligne bien l’isolement des uns par rapport aux autres. Ces îles existent certainement entre les organisations, mais peuvent aussi exister dans chacune d’elles. On croit souvent à tort que la fédération d’identités sert à valider et à sécuriser uniquement des échanges de données entre organisations. En réalité, les organisations ont souvent des îles internes créées pour des raisons de sécurité ou de politique, qui peuvent elles aussi bénéficier de la fédération.

L’établissement d’un lien entre différentes îles organisationnelles fait de la fédération un défi technologique intéressant. Les îles organisationnelles ont généralement leurs propres habitudes et méthodes de travail. Elles ont leurs propres standards de nommage de comptes et leurs propres mécanismes de vérification d’identités (authentification) et de contrôle d’accès aux ressources (autorisation). Les standards de fédérations fournissent une « lingua franca » pour exprimer les données concernant les comptes, l’authentification et l’autorisation, dans un format compréhensible par différents fournisseurs d’identités et de ressources et pour échanger cette information entre partenaires de fédérations.

A l’heure actuelle, il existe trois principaux ensembles de standards de fédération d’identités, appelés threads. Chaque thread a ses champions. Microsoft, avec IBM et VeriSign, favorisent l’ensemble de spécifications appelé thread Web Services-Federation (WS-Federation). L’encadré « Standards de la fédération d’identités » décrit brièvement WSFederation et ses threads rivaux. Les organisations qui envisagent de mettre en place une fédération auront intérêt à utiliser le même standard. Mais ce n’est pas obligatoire : certaines solutions de fédération (comme HP OpenView Select Access et IBM Tivoli Federated Identity Manager) peuvent accepter différents standards de fédération ou traduire un format standard en un autre.

La spécification WS-Federation inclut deux profils de support de fédération : un pour la fédération de clients passifs (aussi appelé profil de requérants passifs) et un de clients actifs (aussi appelé profil de requérants actifs). Les clients passifs sont des navigateurs qui supportent simplement le protocole HTTP et SSL (Secure Sockets Layer) pour sécuriser le trafic HTTP. Un client passif ignore qu’il est utilisé pour la fédération.

Un client actif participe en toute connaissance des protocoles de fédération et il est plus souple, plus puissant et plus sûr qu’un client passif. Les clients actifs supportent en mode natif le SOAP (Simple Object Access Product). Au moment où nous écrivons ces lignes, Microsoft ADFS construit des jetons conformes à Security Assertion Markup Language (SAML) 1.1 et supporte les clients passifs de WS-Federation mais pas les actifs.