La fédération d’identité en entreprise

Un précédent article de Guillaume Plouin montrait l'utilisation de la Fédération d'Identité au sein de sites web grand public et réseaux sociaux, nous allons maintenant voir en quoi elle pourrait s’avérer tout aussi utile pour les applications Métiers.

La Gestion Des Identités et des Accès, (GDI&A ou IAM en anglais) aujourd'hui

Revenons à l'origine sur ce qu'est une identité : il s'agit tout simplement de la représentation numérique d'une personne composée d’un identifiant et d’un ensemble d’attributs (nom, prénom, adresse, téléphone...) aussi appelée “fiche d'identité”. La Gestion des Identités est une problématique plutôt ancienne qui a fait naître un ensemble de bonnes pratiques et d’outils (voir le livre sur la Gestion des Identités).

Une des plus importantes problématiques résolue par la GDI fut l'abondance de comptes utilisateurs que les personnes avaient à retenir et qui se terminaient en post-it (TM) collés à la vue de tous sur leur écran ou sous leur clavier. Comment les blâmer quand on voit la fréquence à laquelle ils doivent changer leur mot de passe et la complexité requise (z$oP6x&1 en janvier, t8%dD2#K en février...). Grâce aux patterns de GDI (Identifiant Unique Personnel, Annuaire central, Synchronisation) et à la normalisation des processus de gestion des personnes, les utilisateurs peuvent maintenant n’avoir qu’un seul compte leur donnant accès à l'ensemble des applications internes du poste de travail aux applications Métiers.

Néanmoins l’ouverture grandissante des SI, due à deux grandes tendances, remet en question cet état de fait :

• les partenariats entre entreprises ou chacune offre ses services aux autres. Services qui se traduisent dans bien des cas par donner l’accès à leurs applications aux collaborateurs des partenaires ;
• l’externalisation accrue : c’était déjà une pratique existante, mais avec le Cloud, les entreprises sont désormais à même de louer leurs applications. Celles-ci repoussent les frontières du SI loin des murs de l’entreprise.

Ainsi pour les utilisateurs, la problématique des comptes multiples resurgit avec les post-it (TM). L’entreprise se retrouve tributaire de prestataires ou partenaires avec qui elle a ouvert son SI : les applications louées dans les nuages (SaaS) n’offrent pas toutes systématiquement des interfaces de provisioning (création / destruction des comptes), de même pour celles d’un partenaire où il faut passer par son Help-Desk pour se voir créer un compte. Enfin les protocoles utilisés jusque là s’avouent difficiles à mettre en oeuvre dans un monde ouvert et le pattern de Synchronisation est complexe voir impossible à mettre en place sur les protocoles réseaux autorisés par la politique de sécurité : c’est HTTP(S) qui dicte ses règles laissant Kerberos et LDAP dans les murs.

Dans le cas où l’entreprise ouvre ses applications à des partenaires, elle doit créer des comptes pour une population qu’elle ne maîtrise pas : les processus de gestion des personnes (arrivée, départ, mutation...) n’existent tout simplement pas ou sont propres à chaque entité. Prenons l’exemple de l’assureur JAssure qui décide de proposer à son partenaire Banking de distribuer ses produits d’assurance. JAssure devrait alors créer des comptes dans son application pour une nouvelle population et “polluer” par la même occasion ses référentiels d’utilisateurs.

Pour répondre à ce genre de problématique aujourd’hui, les modèles classiques de GDI&A apportent d’ores et déjà un certain nombre de solutions :

• l’utilisation de multiples annuaires afin de séparer les utilisateurs de l’entreprise (interne, prestataires...) de ceux de son ou ses partenaires, le service d’authentification devant bien évidement intégrer ce routage entre annuaires pour donner accès aux applications ;
• la mise à disposition d’interfaces de délégation de provisioning à ses partenaires pour que ceux-ci puissent créer, mettre à jour ou supprimer des personnes.

Toutefois ces solutions ont toutes un point commun : elles complexifient l’architecture de sécurité du SI et n’apportent pas de réelles garanties de service aux utilisateurs finaux. Imaginez-vous partir en vacances en Argentine, puis participer à une conférence à Sidney et devoir demander un passeport argentin, puis australien en plus de vos pièces d’identité...

La Fédération d’Identité en action

La Fédération d’Identité vise justement à simplifier la gestion des identités dans un contexte distribué entre plusieurs entreprises. Si on caricature le fonctionnement d’une Fédération d’Identité, on peut imaginer un douanier qui ne fait pas forcément confiance à une personne lui présentant son passeport. Néanmoins notre douanier aura confiance dans le gouvernement qui a délivré le passeport. Ainsi notre individu est authentifié par son gouvernement et présente la preuve de son authentification au douanier qui le laisse alors franchir la douane.

Dans le cadre de la fédération d’identité, on appellera alors Service Provider (SP) une application acceptant les connexions d’un référentiel d’utilisateurs appelé Identity Provider (IDP). Cette interconnexion s’avère possible grâce aux protocoles de Fédération d’Identité tels que SAML, OpenId, Shibboleth ou encore WS-Federation : ils permettent de normaliser et standardiser les échanges d’identité entre les référentiels d’utilisateurs et les applications auxquelles il doit accéder indépendemment de leur localisation. Pour qu’un Service Provider et un Identity Provider puissent dialoguer, il faudra qu’ils fassent partie du même cercle de confiance. Ainsi au sein d’une Fédération d’Identité, on va distinguer plusieurs cercles de confiances regroupant chacun leurs Identity Provider et Service Provider. Le schéma ci-dessous illustre le rôle de chaque acteur au sein d’une fédération.

Si l’on applique ces notions à nos deux entreprises partenaires JAssure et Banking, on peut alors dire que :

• Avec la fédération, l’entreprise JAssure ne gère que ses utilisateurs internes (employés). En tant que fournisseur d’application, elle délègue l’authentification des utilisateurs externes, leur identité est alors transportée depuis l’entreprise partenaire vers JAssure.
• De la même manière, la fédération d’identité va aussi permettre de transporter l’identité des utilisateurs internes de l’intranet de JAssure vers l’Internet ou d’autres SI.

La Fédération d’Identité nous rend donc capable de proposer  à nos utilisateurs un passeport unique pour accéder à ses applications Métiers qu’elles soient internes à son entreprise, louées sur le Cloud ou proposées par un partenaire. Enfin sachez que la mise en place d’une Fédération d’Identité dans votre SI pourra alors être réalisée selon votre choix grâce à des logiciels libres (OpenAM) ou d’éditeurs (Oracle, IBM...) et qu’il existe des sociétés capables de fournir le support dans les deux cas. Un grand nombre d’entreprises ont déjà mis en place un socle de gestion des identités qui leur a permis de bénéficier du SSO, de l’Identifiant Unique Personnel, etc., ce socle est probablement déjà compatible avec les normes de Fédération d’Identité tel que SAML, l’investissement ne sera alors que de la configuration et des tests bien sûr.