Dans de nombreux domaines, les applications Web pour entreprise ont su se rendre incontournables. Plus rapide et moins coûteuses à déployer, avec une complexité d’administration au niveau des infrastructures réseaux, ces applications permettent aussi de simplifier, d’accélérer et d’amplifier les échanges entre l’entreprise et ses partenaires, clients ou fournisseurs.
2.1.1 PRESENTATION DES SOLUTIONS
Il existe trois grandes classes d’approches pour la mise en oeuvre des systèmes d’authentification : les approches centralisées, les approches fédératives et les approches coopératives. Derrière ces approches, on distingue des solutions libres telles que : OpenSSO, SAML, CAS, Shibboleth, OpenID et Liberty Alliance.
2.1.1.1 LA SOLUTION OpenSSO/OpenAM
Portant le nom d’oracle OpenSSO en juillet 2008 puis le nom OpenAM depuis 2010, c’est l’un des serveurs d’authentifications unique et de fédération complet de l’OpenSource.
2.1.1.2 LA SOLUTION SAML
SAML pour Security Assertion Markup Language permet entre autres la délégation d’authentification et sert de fondation à deux autres normes, Shibboleth et Liberty Alliance.
2.1.1.3 LA SOLUTION CAS
C’est un service d’authentification centralisé SSO pour les applications Web, inspiré de Kerberos et basé sur le protocole HTTP(S). CAS pour Central Authentication Service a été développé par l’université de Yale aux Etats-Unis est un serveur d’authentification accessible par WWW, composé de servlets java, qui fonctionne sur tout moteur de servlets (Tomcat par exemple), ce qui fait ses points forts.
2.1.1.4 LA SOLUTION SHIBBOLETH
Shibboleth est développé depuis 2001 par Internet2 et désigne à la fois une norme et un produit open source. C’est une extension de SAML qui enrichit ses fonctionnalités de fédération d’identités, en facilitant pour un ensemble de partenaires la mise en place de deux fonctionnalités importantes : la délégation d’authentification et la propagation d’attributs. Shibboleth a été conçu pour répondre aux besoins des communautés de l’enseignement supérieur et est déjà utilisé dans plusieurs pays : Etats-Unis, Angleterre, Suisse, France, etc…
2.1.1.5 LA SOLUTION OpenID
OpenID implémenté et utilisé par les sociétés clés de l’Internet (Yahoo, MySpace, Google, Microsoft…), propose un protocole ouvert pour une gestion décentralisée d’identités, mettant l’utilisateur au centre des décisions le concernant. OpenID est développé et supporté par la fondation OpenId. Acteurs privés importants: Google, Yahoo, Microsoft et IBM.
2.1.1.6 LA SOLUTION LIBERTY ALLIANCE
Liberty Alliance, implémenté par IBM et utilisé par Sun et Novell, utilise des jetons SAML. Ce modèle a été développé pour répondre à un besoin de gestion décentralisée des utilisateurs, où chaque service partenaire désire conserver la maîtrise de sa propre politique de sécurité, comme par exemple un ensemble de sites marchands indépendants d’un point de vue commercial et organisationnel.
2.1.1.7 LES AUTRES SOLUTIONS
Aucune des sociétés de services internet vivant exclusivement de la publicité (payée par des professionnels) n’est actuellement capable de vérifier et de garantir les données saisies par les internautes. De plus chacune a développé son propre système d’authentification :
– Yahoo avec Yahoo ID
– Microsoft avec Live ID
– Google avec Google Account
– WS-Federation : Standard Web implémenté par Microsoft dans ses produits Active Directory Federation
– Sxipper
– LemonLDAP : NG
2.1.2 LE CHOIX DE LA SOLUTION CAS-SHIBBOLETH
Les solutions d’authentification présentées ci-dessus nous ont permis de voir certaines particularités ou certains avantages des unes par rapport aux autres. Pour répondre aux exigences de notre système, les particularités impressionnantes des solutions CAS et Shibboleth ne nous ont pas laissé seulement le choix de l’un d’entre eux. Nous avons donc associé ces deux solutions et cela se justifie :
CAS est proposé comme mécanisme d’authentification centralisé de web SSO. Il ne traite pas les besoins liés aux autorisations (droits applicatifs), ni aux fédérations d’identités et au transport d’attributs. En outre, la base d’authentification est locale, au niveau de l’établissement. Les aspects inter-établissements ne sont donc pas pris en compte. Par contre, Shibboleth propose un mécanisme de transport d’attributs et d’authentification inter-établissements. De récentes discussions autour de Shibboleth laissent entendre qu’un mécanisme de SSO pourrait être proposé. Mais, Shibboleth à la possibilité de déléguer le SSO à CAS.
CAS
CAS est en production dans plusieurs Universités américaines, avec des authentifications internes Kerberos ou LDAP, ce qui permet d’être confiant sur sa fiabilité.
– La sécurité est assurée par les dispositifs suivants : le mot de passe de l’utilisateur ne circule qu’entre le navigateur client et le serveur d’authentification, nécessairement à travers un canal crypté.
– Des librairies clientes en Java, Perl, JSP, ASP, PL/SQL et PHP sont livrées. Cela permet une grande souplesse sur les serveurs d’applications. L’intégration dans des outils utilisés dans le monde universitaire est d’ores et déjà faite, comme celle d’uPortal.
– L’utilisation de cookies exclusivement privés dans CAS (passage de tickets entre serveur d’authentification et applications uniquement sous forme de paramètres de GET HTTP) permet à CAS d’être opérationnel sur des serveurs situés dans des domaines DNS différents.
– Un module Apache (mod_cas) permet d’utiliser CAS pour protéger l’accès à des documents web statiques, les librairies clientes ne pouvant être utilisées dans ce cas.
– Un module PAM (pam_cas) permet de « CAS-ifier » des services non web, tels que FTP, IMAP, …
SHIBBOLETH
Le Comité Réseau des Universités a retenu Shibboleth pour construire une infrastructure de fédération d’identités pour l’enseignement supérieur français. Surtout la topologie d’une fédération de type Shibboleth correspond bien à la structuration d’un ensemble d’établissements de l’enseignement supérieur. De plus c’est un produit open source, soutenu par une communauté active et ouverte.
. Ouvrir l’accès à une ressource locale (thèses, cours en ligne) à d’autres Etablissements
. Gérer un intranet pour une population disséminée dans plusieurs établissements
On considère ici un groupe de personnes appartenant à différents établissements et amenés à travailler ensemble, donc à partager des documents, des outils de travail collaboratif (forums, wikis, gestionnaires d’enquêtes, autres outils métiers).
. Gérer l’authentification pour des populations à la frontière de l’établissement (anciens ou futurs étudiants)
Les applications de pré-inscription des étudiants ou d’enquêtes auprès des anciens étudiants, concernent des populations qui ne sont pas encore ou plus gérées dans le système d’information de l’établissement. On ne dispose donc pas de service d’authentification pour ces utilisateurs qui ne rentrent pas forcément dans le moule (déjà complexe) des utilisateurs (étudiants, chercheurs, enseignants, autres personnels…).