Print-friendly Version

Eve Maler, avec des contributions de Marina Sum, 29 février 2008

En qualité de déployeur, vous gérez une application logicielle à laquelle des milliers d'employés ou des millions de consommateurs accèdent quotidiennement. Pour chacun d'entre eux, vous gérez un compte, vérifiez des références, contrôlez l'accès aux données ou aux fonctions sensibles et personnalisez l'interface et le comportement de l'application. Pour chacun d'entre eux, vous mettez en oeuvre des moyens humains et financiers considérables afin que l'identité, la confidentialité et la sécurité soient assurées, non seulement du côté positif de la satisfaction de l'utilisateur et de l'efficacité de l'entreprise, mais aussi du côté négatif des violations menaçant l'entreprise.

Aimeriez-vous sous-traiter une partie de votre infrastructure de gestion des identités, l'authentification au début des sessions de connexion utilisateur et même certaines données d'attributs utilisateur, à une source externe ? Inversement, aimeriez-vous présenter une interface à vos comptes utilisateurs, correspondant aux applications dépendant de ces données d'authentification ? Ceci fait l'objet de l'identité fédérée : distribuer les informations et les tâches d'identité à travers des domaines sécurisés, de sorte que les parties concernées puissent se concentrer sur leur spécialité professionnelle.

Pourquoi déployer l'identité fédérée ? Pour le moment, elle a été principalement utilisée pour les connexions uniques (SSO)entre domaines, pour épargner du temps et des complications à l'utilisateur et pour éliminer les réinitialisations coûteuses des mots de passe. Grâce à la SSO, les utilisateurs peuvent s'authentifier à un endroit et accéder ensuite à des ressources protégées à d'autres endroits. Par exemple :

• Les entreprises qui sous-traitent les fonctions comme les ressources humaines et l'assurance santé, se tournent vers la SSO.
  
  
• De nombreux gouvernements adoptent la SSO pour les portails citoyens et l'accès aux applications inter-agences pour les fonctionnaires.
  
  
• Les institutions académiques gèrent souvent l'accès aux bases de données de recherche des universités partenaires avec la SSO.

Dans tous les cas, les mêmes acteurs sont concernés, c'est-à-dire :

• Les utilisateurs et les agents, comme les navigateurs, à travers lesquels ils communiquent en ligne
  
  
• Les fournisseurs de service (SP, Service Providers) qui proposent des applications Web et s'appuient sur des sources externes pour les contributions essentielles à leurs décisions d'autorisation
  
  
• Les fournisseurs d'identité (IdP, Identity Providers) qui authentifient les utilisateurs et gèrent les attributs d'intérêt commun

La Figure 1 illustre les interactions.

Figure 1 : acteurs SSO

Pour protéger l'identité et les données d'application transmises, les IdP et les SP établissent généralement un cercle de confiance avec des accords techniques et commerciaux qui définissent leurs responsabilités respectives. Un cercle de confiance adopte souvent une topologie en étoile, avec un seul IdP et de nombreux SP dans le rôle des pointes, qui font confiance à l'IdP mais pas nécessairement aux autres SP. Le rôle de l'IdP est plus complexe car il doit fournir l'infrastructure d'identification ainsi que la plupart des mesures de sécurité. Les SP, qui recherchent la simplification en sous-traitant à l'IdP, attendent qu'on leur propose des boîtes à outils facilitant le déploiement.

Quel rôle vous convient ? En fonction des réalités commerciales, le choix peut être évident ou indépendant de votre volonté. Considérez ces exemples :

• Une société de ressources humaines qui propose des applications de gestion des profils des employés aux entreprises est un SP naturel pour ses clients, qui servent à leur tour d'IdP. Chacun des IdP met son répertoire d'employés à disposition, de façon limitée.
  
  
• Une université peut fonctionner comme suit :
  
  
  • Comme IdP pour ses propres étudiants et comme faculté lorsqu'ils accèdent aux données de recherche des universités partenaires
  • Comme SP référentiel de recherche pour les étudiants et comme faculté sur ces sites partenaires
  
  Cet arrangement constitue un véritable cercle de relations de confiance.

Le choix du protocole d'identité fédérée détermine le langage dans lequel les parties communiquent : les formes et la signification des messages. Une fois encore, en fonction des relations commerciales, le choix peut ne pas vous appartenir.

SAML
Le protocole le plus complet et le plus largement déployé est le Security Assertion Markup Language (SAML, prononcé sam, actuellement dans sa version 2.0. La conception du SAML 2.0 résulte de la fusion des capacités du SAML 1.1, du protocole Shibboleth SAML utilisé dans l'enseignement supérieur et des protocoles Liberty Alliance connus sous l'appellation Identity Federation Framework (ID-FF).

Vous avez peut-être rencontré certains de ces protocoles plus anciens, qui sont toujours activement déployés. Ils représentent un langage unique car leurs syntaxes sont compatibles entre elles.

WS-Federation
WS-Federation est un protocole assez similaire qui a été développé indépendamment. Sa genèse Microsoft fait qu'il est le plus souvent choisi pour les IdP et les SP qui partagent une identité et des plates-formes de service Web sur base Microsoft.

Le protocole InfoCard de Microsoft, qui régit son implémentation Windows CardSpace, offre un moyen d'authentification Web résistant au phishing et un partage des attributs qui s'intègre bien au concept de SSO. Pour adopter le paradigme CardSpace, vous devez vérifier qu'un agent spécial, appelé sélecteur d'identité, est déployé sur les systèmes clients de vos utilisateurs.

OpenID
Le protocole OpenID est centré sur la simplicité et la facilité de déploiement SP, en particulier pour les sites Web 2.0. OpenID présume d'un manque de confiance total. En d'autres termes, n'importe qui peut créer un identifiant OpenID (un URI) et héberger un IdP. Les SP qui choisissent d'accepter les connexions OpenID le font sans configurer de relations de confiance avec les IdP par avance. Une telle configuration évite le processus lourd de déploiement d'un SP, mais limite vos options en termes de fiabilité du partenaire et de sécurité du système.

Sun Solutions
Pour aider les déployeurs qui nécessitent plusieurs protocoles ou de la souplesse, Sun Java System Access Manager et son pendant Open Source OpenSSO sont devenus polyglottes. Ils fonctionnent non seulement avec SAML, ID-FF et WS-Federation, mais offrent également une extension pour OpenID. La prise en charge du protocole InfoCard par l'intermédiaire d'une extension est à l'étude. Cette vaste couverture répond à de nombreuses préoccupations liées aux protocoles en termes de fédération et de gestion d'accès au Web.

Notez que, dans sa version 8.0 à venir, Sun Java System Access Manager sera fusionné avec Sun Java System Federated Manager pour former Sun Java System Federated Access Manager.

Pour permettre des intégrations homogènes entre protocoles, Sun est co-fondateur et participant d'une communauté intitulée Projet Concordia. Ce projet étudie les problèmes d'interopérabilité soulevés par les déployeurs et collabore avec eux et les fournisseurs pour développer des pratiques recommandées et documenter des solutions testées dans le temps.

Il est rare de pouvoir configurer une application avec un ensemble idéal de relations d'identité fédérées dès le départ. Par exemple, lors de la création d'un portail regroupant des applications existantes, une SSO est souvent ajoutée à un environnement d'application qui gère déjà ses propres "comptes locaux" et doit continuer à le faire. Vous devez alors lier chaque compte local d'un SP à un compte de l'IdP pour le même utilisateur, afin que sa connexion à l'IdP résulte en une SSO au bon compte SP.

Vous pouvez lier les comptes (une tâche au nom parfois déroutant de fédération identitaire) dans une opération par lot. Toutefois, pour les applications destinées aux consommateurs, la tâche est souvent exécutée de façon interactive avec l'aide et le consentement en temps réel de l'utilisateur. Par exemple, si vous êtes un utilisateur Flickr, vous pouvez vous rappeler comment ce site vous a invité à lier votre compte à votre compte Yahoo!

Le passage des connexions locales à la SSO peut perturber les utilisateurs s'ils doivent s'authentifier avec une ID utilisateur différente sur un autre site, éventuellement par l'intermédiaire d'un processus différent (par exemple avec des cartes à puce au lieu des mots de passe). Dans le cas de Flickr, les utilisateurs ont disposé d'une période d'adaptation pendant laquelle les deux connexions fonctionnaient.

Vous devez aussi tenir compte du type de navigation que vous souhaitez offrir aux utilisateurs. Voici deux styles de déploiement courants :

• Portail (SSO initiée par l'IdP)Du point de vue système, ce scénario dans lequel l'utilisateur commence à naviguer chez l'IdP et n'a qu'à suivre un lien vers le SP voulu, est le plus simple.
  
  
• Marque-page (SSO initiée par le SP)Dans ce scénario, l'utilisateur visite le SP en premier et, lorsqu'il accepte d'accéder à une page ou une fonction protégée, il est renvoyé vers l'IdP pour se connecter, ce qui produit davantage d'échanges de messages entre les systèmes. En outre, le SP doit déterminer où envoyer l'utilisateur pour se connecter - une énigme notoire appelée problème de détection de l'IdP.
  
  Les solutions à ce problème nécessitant des compromis, vous devez déterminer ce qui vous importe le plus : confort pour l'utilisateur, souplesse architecturale ou limitation des coûts.

Avant de choisir votre architecture SSO, évaluez ces trois questions importantes :

• Votre solution concerne-t-elle des utilisateurs Internet de passage, des membres d'un service payant, des employés ?
  
  La réponse affectera votre capacité de contrôle des systèmes clients des utilisateurs et suggérera des stratégies de protection des données, de confidentialité et de collecte du consentement des utilisateurs.
  
  
• Les transactions comportent-elles une valeur monétaire importante, ou s'agit-il d'échanges de données relativement triviales ?
  
  La réponse détermine votre stratégie de sécurité et la part de votre stratégie consacrée à établir la confiance.
  
  
• La confiance doit-elle être préalablement établie avec vos partenaires en ligne ? Dans l'affirmative, quelle topologie de confiance serait adaptée ?
  
  La réponse détermine votre choix technologique, des contrats commerciaux et des pratiques de coordination à long terme avec vos partenaires.

Un flot d'autres considérations pratiques suit :

• Devez-vous lier les comptes locaux existants aux comptes de l'IdP ? Dans l'affirmative, devez-vous établir chaque lien avec la contribution de l'utilisateur en temps réel ?
  
  
• Qu'advient-il si un compte est fermé d'un côté ?
  
  
• Quelle méthode d'authentification vous faut-il ? Votre protocole prend-il en charge les communications en rapport avec cette méthode ?
  
  
• Comment et quand les attributs utilisateurs doivent-ils être partagés, et avec quel modèle de consentement utilisateur ?
  
  
• Voulez-vous adopter la déconnexion unique ? En d'autres termes, lorsqu'un utilisateur se déconnecte, cette déconnexion doit-elle être répercutée à toutes ses sessions chez ce SP, ou même à toutes ses sessions chez tous les SP basées sur la connexion d'origine à l'IdP ?
  
  Qu'en est-il des délais d'expiration de connexion ?

Ne vous sentez pas submergé. Étudiez OpenSSO (et bientôt Federated Access Manager 8.0), qui adopte une approche d'assistant et vous guide à travers les écrans de configuration pour un déploiement plus rapide et plus intuitif. La distribution efficace des tâches et des informations d'identité peut bénéficier de la même manière aux utilisateurs, aux détenteurs des comptes et aux propriétaires des applications. OpenSSO peut vous aider à tous les aider.

• Sun Java System Access Manager
  
  • Page principale
  • Accueil développeur
  • Forum logiciels
  • Documentation
  
  
• Sun Java System Federated Access Manager à venir
  
  • Présentation architecturale
  • FAMTalk
  
  
• Projets open-source associés, lieux standard et communautés
  • OpenSSO
  • Extension OpenID pour OpenSSO
  • WS-Federation
  • SAML
  • OpenID
  • Projet Concordia
  • Le système identitaire open-source
  
  
• Description et comparaison de SAML, OpenID et du protocole InfoCard de CardSpace (PDF)
  
  
• Assistance développeurs Sun
  • Support :
  • Formation et certification

Unless otherwise licensed, code in all technical manuals herein (including articles, FAQs, samples) is provided under this License.