Shibboleth – un sso ++

Nous avons évoqué, lors de précédents billets, le fonctionnement de Shibboleth basé sur la norme SAML 2.0.

La norme décrit les échanges entre le Service Provider (SP), qui protège les services, le Discovery Service (DS) qui permet à l’utilisateur d’indiquer son fournisseur d’identités et l’Identity Provider (IdP), qui assure l’authentification des utilisateurs.

Au sein d’une même entreprise, le déploiement d’une telle solution est comparable aux solutions de SSO standard, avec toutefois des avantages non négligeables.

Standard et souplesse d’intégration

Shibboleth n’est conçu que sur des standards reconnus et normalisés :

• XML pour les fichiers de configuration et les échanges entre les composants IdP, SP et DS
• SOAP pour l’enveloppe des assertions SAML
• WS-Signature pour la signature des assertions SAML
• WS-Encryption pour le chiffrement des assertions SAML
• SAML 2.0 pour le respect des profils de fédération d’identité
• LDAP/SQL pour l’accès aux référentiels d’identités et d’habilitations
• Redirections http pour la compatibilité avec les navigateurs du marché

L’IdP et le DS sont deux applications Java qui s’installent dans tous les serveurs d’applications Java du marché et de l’open source.

Le SP est composé d’une part d’un filtre serveur Web dont des versions compilées existent pour Apache et IIS et d’autre part d’un service autonome qui s’installe aussi bien sous Windows que sous Linux.

Bien que Shibboleth soit limité en fonctionnalité d’authentification, il est tout à fait envisageable de développer ses propres servlets d’authentification. Il est également possible de déléguer, assez facilement, l’authentification au célèbre outil de SSO, CAS (Central Authentication Service http://www.jasig.org/cas). Il permet les authentifications Active Directory, JAAS, JDBC, LDAP, Legacy, RADIUS, SPNEGO, Trusted et par certificats X.509.

Sécurité renforcée

Il est remarquable de constater que dans l’acronyme SSO, qui correspond à Single-Sign On, il n’y ait aucun « S » qui signifie « sécurité ». Or, avec Shibboleth, réduit à une simple fonctionnalité de SSO, la sécurité est belle et bien présente :

• L’authentification utilisateur, peut être renforcée, par l’usage de certificats X.509 clients, par exemple en connectant CAS à Shibboleth.
• Les SP importent les certificats serveurs des IdP qu’ils autorisent à leur fournir une authentification utilisateur. Ainsi, le cercle de confiance est bien défini et sécurisé : Les SP n’acceptent pas de n’importe quel IdP une authentification utilisateur.
• Les IdP peuvent aussi importer les certificats des SP. Ainsi, seuls les SP autorisés peuvent demander une authentification utilisateur.
• Les assertions sont chiffrées par des clés asymétriques (cf. WS-Encryption).
• Les assertions sont signées par les certificats serveurs, des IdP pour les SP et des SP pour les IdP (cf. WS-Signature).
• Chaque donnée d’utilisateur dans les assertions à destination des SP peut être chiffrée et signée, indépendamment de l’assertion, par le certificat serveur de l’IdP.
• Des mécanismes peuvent être configurés dans le but de présenter à l’utilisateur l’ensemble des données le concernant à destination du SP, pour validation, avant que l’IdP ne les transmette. Ainsi, l’utilisateur est maître des données le concernant qu’il veut transmettre aux services distants.

Atoûts

La plus part des solutions de SSO web se limitent à l’authentification des utilisateurs ; elles ne traitent pas des besoins liés aux autorisations (droits applicatifs) ni au transport d’attributs. En outre, leur base d’authentification est locale, au niveau du domaine de la compagnie. Les aspects inter-compagnies ne sont donc pas pris en compte.

Le projet Shibboleth propose un mécanisme de transport d’attributs et d’authentification inter-compagnies. Shibboleth sait transmettre des informations sur l’identité et les habilitations de l’utilisateur qui désire accéder à une ressource protégée. Ce que ne dit pas SAML, c’est l’art et la manière de récupérer ces attributs dans les référentiels.

La norme SAML prévoit le transport d’attributs supplémentaires avec les accréditations de l’utilisateur. Shibboleth est donc capable de transmettre, par exemple, le profil de l’utilisateur avec son identité, en même temps que la preuve d’une authentification réalisée avec succès.

Il est donc envisageable de pouvoir transmettre, en plus de l’identité de l’utilisateur, un ensemble d’attributs utiles au service que cet utilisateur veut atteindre, comme le rôle de l’utilisateur, son nom, son prénom ou son domaine d’appartenance…

Conclusion

Shibboleth, solution de fédération d’identité, est aussi une solution de Web-SSO interne à l’entreprise. Cette solution est fortement sécurisée et permet l’adjonction d’attributs propres aux utilisateurs comme le rôle permettant de déduire directement leurs privilèges.

Une application qui sait gérer le rôle de l’utilisateur en entrée, est beaucoup plus facile à réaliser. Seul les rôles sont à gérer au niveau de l’application et non l’ensemble des comptes autorisés à y accéder.

Dans un prochain billet, nous montrerons comment sont gérés les attributs des utilisateurs entre le référentiel d’identités/habilitations et l’application qui les demande.

Thierry ALBAIN

Filed under: Articles Tagged: fédération, IAM, identité, SAML, sécurité, SSO