La sécurité apportée par Shibboleth

La sécurité apportée par Shibboleth
Le logiciel Shibboleth [Shibboleth] vise à faciliter et sécuriser l'accès à des ressources extérieures au périmètre du système d'information d'un établissement. Shibboleth améliore la sécurité :
1. en réutilisant les services (authentification, référentiels) déjà existants dans le système d'information d'un établissement ;
2. grâce à des mécanismes de diffusion contrôlée des attributs et de gestion de l'anonymat ;
3. en s'appuyant sur des standard éprouvés (SAML, TLS, X.509) ;
4. Shibboleth améliore également le modèle de sécurité d'une application en incitant à distinguer l'authentification de l'autorisation.
Réutilisation des services déjà existants dans le système d'information
Shibboleth est conçu pour s'appuyer sur les services déjà existants dans le système d'information d'un établissement. Avec Shibboleth, l'authentification à une ressource s'appuie sur le service d'authentification de l'établissement (typiquement son SSO, par exemple CAS). L'application bénéficie directement du niveau de sécurité qu'a déjà mis en place l'établissement pour son système d'authentification pour ses besoins internes. L'établissement n'expose pas à l'extérieur les données d'authentification de ses usagers, car seules des preuves d'authentification sont diffusés aux applications extérieures. Une application extérieure n'a pas alors à implémenter un système d'authentification ad hoc, avec tous les risques associés : conception et implémentation défaillantes, gestion défaillante (car fastidieuse) de comptes et mots de passe, utilisation par les usagers de mots de passe triviaux (pour réussir à s'en souvenir) ou réutilisation du mot de passe de leur SSO (qui est alors exposé à l'extérieur de l'établissement). Shibboleth permet également à une application d'obtenir des attributs issus des référentiels (annuaire LDAP, bases métier SQL) du système d'information de l'établissement de l'utilisateur. Ces attributs sont diffusés de l'établissement à l'application quand un usager accède à l'application. Elle s'affranchit ainsi du maintien en interne d'une liste d'attributs sur les usagers. Ces attributs ont un niveau de fiabilité élevé, car ils sont issus de référentiels et déjà utilisés par l'établissement pour ses propres besoins. Ils peuvent ainsi servir pour réaliser la phase d'autorisation à l'accès à l'application et déterminer le niveau des droits de l'usager dans l'application.
Contrôle de la diffusion des attributs et de gestion de l'anonymat
La diffusion des attributs depuis le système d'information d'un établissement vers une application est contrôlée. Shibboleth permet à l'établissement d'implémenter une politique de diffusion des attributs, en fonction des besoins exprimés par les applications extérieures et des contraintes de l'établissement concernant la protection des données à caractère personnel. L'établissement peut ainsi diffuser plus ou moins d'attributs en fonction des applications, voir du profil des usagers. Il existe de plus des logiciels [Autograph] [ArpViewer] pouvant se greffer à Shibboleth et qui permettent de donner le contrôle à l'usager sur l'exportation de ses données à caractère personnel.
Par défaut Shibboleth ne diffuse aucune information nominative de l'établissement vers l'application. Seul un identifiant utilisateur anonyme et temporaire est généré par Shibboleth ; cet identifiant sera utilisable par l'application pour maintenir une session avec l'utilisateur. Ce mécanisme offre la possibilité d'un accès authentifié mais anonyme à une ressource extérieure : authentifié car l'application reçoit de l'établissement une assertion prouvant que cet usager s'est correctement authentifié dans l'établissement, mais anonyme car l'application ne reçoit aucune information nominative sur cet usager. Shibboleth permet également l'utilisation d'un identifiant anonyme mais persistant, ce qui offre la possibilité de personnaliser l'utilisation anonyme d'une ressource (un utilisateur peut être reconnu d'un accès à l'autre par la ressource, sans qu'elle ne connaisse son identité nominative). Un établissement décide s'il diffuse en plus des attributs nominatifs vers une application.
Ces mécanismes de gestion de la diffusion des attributs et de l'anonymat sécurisent le mécanisme de propagation d'attributs en dehors du périmètre d'un établissement, et garantissent la possibilité de satisfaire à la réglementation relative au traitement des données à caractère personnel.
Utilisation de standard éprouvés
Shibboleth s'appuie sur des standard éprouvés pour sécuriser les données et les échanges effectués entre les briques Shibboleth :
●
●
SAML [SAML] pour définir le format des données échangées (assertions d'authentification et d'attributs) et les protocoles d'échanges de ces données ;
TLS [TLS] et les certificats X.509 [X.509] pour la signature des messages XML, pour l'authentification mutuelle des briques fournisseurs d'identités et de services, pour le chiffrement des échanges de données.
Le produit a été conçu en distinguant clairement l'implémentation logicielle Shibboleth et la spécification Shibboleth [Shibboleth]. L'implémentation et la spécification ont été développées par des experts en sécurité et en fédération d'identités de la communauté universitaire américaine, qui ont contribué activement au standard SAML et qui développent également le produit OpenSAML [OpenSAML].
Shibboleth est un produit open source. Ses avis de sécurité sont publiés sur la page http://shibboleth.internet2.edu/secadv/ .
Distinction de l'authentification et de l'autorisation
Souvent, lors de la phase de développement d'une application, la confusion entre les phases d'authentification et d'autorisation compliquera son interfaçage ultérieur avec le système d'information d'un établissement : système d'authentification fermé, pas de possibilité de correspondance entre des attributs issus d'un référentiel extérieur et les rôles applicatifs. Ce manque d'ouverture d'une application nuit à la sécurité en amenant à dupliquer des informations et assurer des mécanismes de synchronisation de ces informations avec le système d'information. Les risques sont une plus grande exposition de ces informations et l'utilisation d'informations qui ne sont pas à jour. L'architecture de Shibboleth fait clairement la distinction entre la phase d'autorisation et la phase d'autorisation à l'accès d'une ressource. L'utilisation de Shibboleth peut améliorer le modèle de sécurité des applications accédées.
Références
[Shibboleth] Shibboleth software and protocols
http://shibboleth.internet2.edu/
http://shibboleth.internet2.edu/docs/internet2­mace­shibboleth­arch­protocols­latest.pdf
[Autograph] Autograph – a personal privay manager
http://www.federation.org.au/twiki/bin/view/Federation/AutographView
[ArpViewer] ArpViewer
http://www.switch.ch/aai/support/tools/arpviewer.html
[SAML]
Security Markup Assertion Language
www.oasis­open.org/committees/security/ [TLS] Transport Layer Security
http://tools.ietf.org/wg/tls/ [X.509]
Public­Key Infrastructure (X.509)
http://tools.ietf.org/wg/pkix/ [OpenSAML]
http://www.opensaml.org/