Architectures d’identification Web

L’authentification unique (SSO)

Le « Single Sign-on » (SSO) désigne les technologies qui permettent aux utilisateurs de mutualiser la phase d’authentification entre plusieurs services. Concrètement il s’agit de ne solliciter l’authentification de l’utilisateur qu’une seule fois alors que ce dernier utilise différentes applications. A titre d’exemple on peut penser à l’authentification Google qui est partagée entre les différents services Gmail, Youtube, Google Apps etc.

Dans ce mode de fonctionnement Google est le fournisseur d’identité (IdP) pour ses propres services. Ces services sont dénommés « fournisseur de service » (SP).

La délégation de validation d’identité

La délégation de la validation de l’identité de l’utilisateur consiste à utiliser un compte valable sur X pour accéder au service Y. L’exemple courant est ici le compte Facebook qui permet désormais de se connecter à différents services totalement indépendants de Facebook. Ces services font le choix de faire confiance à Facebook pour la validation de l’identité d’un utilisateur.

Dans ce mode de fonctionnement Facebook est le fournisseur d’identité (IdP) tandis que le service tiers est le fournisseur de service (SP).

Mode mixte

Le SSO mono-entreprise comme celui de Google existe depuis longtemps. Récemment des normes d’échange ont été standardisées afin de permettre la communication entre IdP et SP. Il devient alors possible d’utiliser en parallèle plusieurs IdP et plusieurs SP. Les protocoles les plus courants sont SAML et OpenID. Ces deux protocoles sont portés par des consortiums différents. Bien qu’incompatible entre eux, ils implémentent globalement les mêmes mécanismes.

SSO sur application externe

Les techniques comme SAML permettent de gérer des problématiques concrètes dans les DSI d’aujourd’hui. C’est notamment le cas pour le partage de l’authentification interne avec une application externe.

Problématique

De nombreuses applications d’entreprise sont désormais déployées sur le Cloud en mode totalement externalisé. Certains acteurs SaaS comme salesforce.com en font même leur principal argument. Dans ce mode l’authentification des utilisateurs est un problème récurrent. Jusqu’ici la DSI était confrontée à un choix cornélien.

L’application SaaS gère seule sa base d’utilisateurs

Dans ce mode chaque utilisateur dispose d’un login / mot de passe propre à l’application. Cet accès est indépendant des accès qui existent en interne. La DSI évite ainsi d’exposer son référentiel interne et les mots de passe à un fournisseur externe. Néanmoins les inconvénients sont nombreux :

• gestion difficile de multiples mots de passe pour l’utilisateur
• impossibilité de gérer les comptes (création / suppression)
• non transmission des informations RH (départ, mutation, congé long)
• duplication des informations

Ces problèmes s’aggravent à mesure qu’on multiplie les applications externes et les sollicitations du support s’enchaînent : Monsieur X a perdu son mot de passe pour l’application Y, il faut alors solliciter le support du fournisseur etc.

L’application SaaS accède à la base d’utilisateurs interne

Ici l’application externe a été configurée pour accéder au référentiel interne des utilisateurs, par exemple l’Active Directory. L’accès est alors simplifié pour les utilisateurs qui peuvent utiliser leur compte habituel. Néanmoins l’entorse faite à la sécurité est manifeste avec un accès majeur donné à un fournisseur externe. De nombreux problèmes apparaissent :

• Les fournisseurs de service ont accès aux mots de passe internes
• Des flux spécifiques doivent être ouverts (LDAP bien souvent)
• Une intrusion chez le fournisseur devient une intrusion pour le client

Avec plusieurs fournisseurs SaaS on se retrouve rapidement avec des dizaines de flux LDAP/LDAPS ouverts à travers Internet vers l’Active Directory.

Autres solutions classiques

Certaines DSI, conscientes des problématiques, choisissent de sécuriser les flux avec des tunnels IPSEC. D’autres ont recours à des systèmes complexes de Token physiques ou d’authentification forte par certificats ou cartes à puce. Bien que l’on puisse parvenir à un équilibre satisfaisant entre sécurité et praticité, les architectures deviennent rapidement d’une grande complexité.

La solution SAML

Grâce à SAML la DSI peut implémenter son propre portail d’identification (IdP). Celui-ci assurera en toute autonomie l’authentification des utilisateurs. Cette identité sera transmise aux fournisseurs de service habilités au travers d’un échange SAML. Dans cette transmission le fournisseur (SP) n’aura accès qu’aux seules informations strictement nécessaires.

Authentification

Lors de la connexion à l’application externe, celle-ci renvoie l’utilisateur inconnu vers l’IdP de l’entreprise. Cet IdP est un service web accessible en HTTPS. Il peut être hébergé en interne ou en externe.

Authentification interne

L’utilisateur prouve ensuite son identité à l’IdP. Cette phase peut se faire par une authentification explicite (login / mot de passe) ou par la propagation d’un jeton préexistant. C’est notamment possible dans le cas d’une authentification Kerberos sur un domaine Active Directory. Dans ce dernier cas la phase d’authentification est transparente pour l’utilisateur.

Génération de l’assertion

L’IdP va alors générer un « jeton », sorte de carte d’identité de l’utilisateur, valable uniquement pour le service sollicité et pour un temps donné. Dans ce jeton on trouvera notamment :

• L’identité de l’utilisateur : login, email ou autre champs
• Des attributs supplémentaires facultatifs : nom, prénom, langue etc.
• Une période de validité du jeton
• Une signature du jeton par l’IdP

Transmission de l’IdP vers le SP

Dans le mode le plus pratique, l’assertion n’est pas transmise directement de l’IdP vers le SP, mais par l’intermédiaire de l’utilisateur lui-même. Par un mécanisme de rebond HTTP, l’IdP va fournir au navigateur client le jeton à transmettre au fournisseur de service. On peut comparer à la carte d’identité fournie par la préfecture pour être présentée à toute autorité.

Consommation du jeton par le SP

Le fournisseur de service reçoit le jeton de la part de l’utilisateur. Le SP a choisi de faire confiance à cet IdP. Aussi valide-t-il la signature et l’intégrité du jeton, ainsi que la période de validité. Si les tests sont concluants le SP ouvre une session à l’utilisateur.

Modalités pratiques

La mise en place d’un IdP interne à l’entreprise n’est pas très complexe. Il s’agit principalement d’un serveur Web embarquant un composant capable de générer des jetons SAML ou OpenID. Le composant libre simpleSAMLphp est particulièrement polyvalent et souple.

Du côté des fournisseurs de service il faut valider que ceux-ci acceptent un mode d’authentification implémenté par l’IdP. On choisira en général SAML 2.0, OpenID ou Shiboleth.

Source d’identité Cloud

Les techniques comme SAML permettent de gérer des problématiques concrètes dans les DSI d’aujourd’hui. Certaines d’entre elles font le choix d’une architecture intégralement Cloud.

Problématique

Dans ce mode de fonctionnement le fournisseur principal devient la référence pour l’identité des utilisateurs. En général la DSI a choisi d’héberger ses applications et sa messagerie sur Google Apps ou Microsoft Office365. Il devient alors crucial de pouvoir utiliser l’identité externe auprès d’application internes ou même d’autres applications externes.

La solution SAML / OpenID

Ici les protocoles SAML et OpenID vont permettre de rapatrier l’identité de l’utilisateur sur une application interne. Par exemple l’utilisateur authentifié sur son compte Gmail et automatiquement reconnu sur l’application interne qui implémente le mécanisme. A ce titre l’utilisateur bénéficie des fonctionnalités de gestion d’identité de Google Apps : authentification forte, répudiation, gestion centralisée des comptes etc.

Modalités pratiques

Plusieurs composants logiciels permettent de « consommer » les assertions SAML ou OpenID. On peut citer simpleSAMLphp ou encore mod_auth_openidc (module Apache). Les applications internes ne nécessitent que des modifications mineures pour tirer parti de l’authentification externe.

Mode gré-à-gré

Lorsque deux entités différentes doivent collaborer, les échanges relatifs à l’authentification des utilisateurs sont particulièrement problématiques. Le protocole SAML permet de gérer efficacement ces cas de figure.

Problématique

La société A veut fournir un service à la société B sous forme d’une application Web. Afin de faciliter les interactions on souhaite que les utilisateurs disposent des mêmes comptes en interne qu’en externe. De nombreux problèmes se posent alors :

• Comment synchroniser les informations ?
• Comment gérer les doublons qui pourraient exister entre A et B ?
• Comment traiter les expirations de mots de passe, les suppressions ?
• Comment gérer des notions comme les groupes ou les permissions ?

La solution SAML

Plutôt que de monter des systèmes d’échange d’informations spécifique, il est extrêmement efficace d’utiliser ici le protocole SAML ou l’un de ses équivalents.

Le fournisseur d’identité
La société A doit fournir à la société B un service. La société B doit quant à elle fournir l’information d’authentification à A. Aussi elle doit intégrer un service IdP au sein de son système d’information.

Le fournisseur de service
La société A fournit le service, elle va « consommer » les jetons d’authentification fournis par B. La société A est le « Service Provider » (SP).

Échange de clef
Une fois les deux composants en place, les DSI vont échanger leurs clefs publiques respectives. Celles-ci permettent de valider l’identité du fournisseur d’identité au fournisseur de service, et vice-versa.

Attributs étendus
Si cela est nécessaire, la société B peut inclure des informations complémentaires dans l’assertion SAML. Par exemple elle peut transmettre, en plus du « login » de l’utilisateur, ses nom et prénom, ou l’information d’appartenance à un groupe AD par exemple. Cette appartenance permettra au SP d’attribuer des droits particuliers à cet utilisateur.

Avantages

A aucun moment le fournisseur de service n’a accès au Système d’Informations du partenaire. Seules les informations strictement nécessaires lui sont transmises.
Autre avantage le déploiement, tant côté IdP que SP, est particulièrement rapide et non intrusif.
Les jetons d’authentification SAML sont véhiculés intégralement en HTTPS et par l’intermédiaire du navigateur client. Aucun flux réseau supplémentaire n’est nécessaire.
L’architecture mise en place peut être réutilisée pour d’autres échanges avec un tiers, côté IdP comme côté SP.