|
|
||
| Date de création : | 12 mars 2003 | |
| Dernière modification : | ||
| Diffusion : | internet | |
L'utilisation de LDAP à des fins d'authentification a permis d'offrir à chaque étudiant et chaque personne participant au fonctionnement de l'Université un compte unique (login / mot de passe) pour accéder aux différentes ressources informatiques.
Se pose maintenant le problème des authentifications multiples : il est nécessaire de se ré-authentifier lors de l'accès à chaque application. Ce désagrément risque d'être encore plus sensible avec la mise en oeuvre d'application 'portail'.
La perspective de développement de campus numériques pose également le problème du développement d'un mécanisme de SSO inter-établissement.
Ce site est un support de réflexion sur les techniques envisageables, et les implications au niveau des annuaires LDAP.
Les documents proposés ici sont juste des documents de réflexion.
Sont présenté ici des documents issus d'une première réflexion menée au sein de l'Université, entre l'équipe système / réseau, et les développeurs d'applications web.
Ce ne sont pas des documents finalisés ; les techniques exposées ne sont pas à mettre en oeuvre telles qu'elles : elles sont insuffisantes au niveau sécurité et fiabilité du service. Ca nous a néammoins permis de réfléchir sur la problématique, et d'avoir une idée plus précise sur les solutions éventuelles.
Elles s'appuient sur les techniques décrites par les différents projets listés en bas de cette page.
Le document SSON2-base.doc (version 2002112302) décrit les grandes lignes du mécanisme.
Une maquette d'essai est accessible à :
http://cridev.univ-nancy2.fr:7999/PORTAIL/
Elle a été montée d'une manière très rapide
(une personne pour une journée). Elle est loin d'être parfaite.
Elle a été montée pour tester les mécanisme de
redirection et de session.
Un document power point (SSON2.ppt) permettant d'illustrer ces mécanismes sera mis rapidement à disposition.
Voir la page du CRU consacrée au SSO.
Voir la doc du CAS, mécanisme de SSO choisi dans le cadre d'esup-portail.
On peut trouver à cette adresse un comparatif de différentes solutions.
Sont exposés ici des implémentation
non commerciales existantes, ou des projets libres en cours.
Ces projets s'appuient sur des clients web standards, sans plug-ins ou autres
modifications contrairement à la plupar des solutions commerciales.
Il y a une grande similitude dans les implémentation proposées; en particulier, on retrouve systématiquement la notion de 'session' globale au niveau du serveur d'authentification, avec l'ID de session passé en cookie, et une notion de 'jeton applicatif' qui valide un utilisateur pour une application.
Dans tous les cas, c'est le navigateur client qui accède au serveur d'authentifcation, via des redirections http.
On peut remarquer que la plupart des implémentations couvrent le SSO 'local', c'est à dire à l'intérieur d'un établissement.
2 implémentations (Shibboleth et PAPI) traitent d'un mécanisme inter établissement, sans proposer de mécanisme intra établissement.
Enfin, le projet CAS de l'Université de Yale, dans sa version 2, propose un mécanisme de proxy qui semble très intéressant.
On distingue également des techniques qui ne couvrent que l'authentification, alors que d'autres traitent également des droits d'accès et du transport d'informations complémentaires.
Seul, PubCookie propose un module apache qui permet d'interfacer les mécanismes internes d'authentification apache (htaccess et require user) avec le SSO.
Cette implémentation fait l'objet d'une étude détaillée dans ce document.
SSO local. C'est un regroupement
d'universités
principalement américaines qui travaille sur le SSO.
Pour le moment, WebISO ne propose pas d'implémentation, mais des spécifications
sur ce qui est nécessaire pour un projet inter opérable et fiable
(voir le document
sur les pré-requis, très intéressant).
La home page du projet est accessible à : http://middleware.internet2.edu/webiso/
WebISO propose les techniques nécessaires à un mécanisme limité à l'authentification, et dans un environnement intra - établissement.
Local. C'est un mécanisme d'authentification pour applications web utilisé à l'Université Berkeley ; ce n'est à priori pas un mécanisme de SSO.
Voir http://istpub.berkeley.edu:4201/bcc/Fall2001/infr.aws.html et les liens qui en découlent.
http://www.brown.edu/Facilities/CIS/Network_Services/web-auth/
SSO local. Développé en perl. Délivre un 'master ticket' et des 'services tickets' sous la forme de cookies http. Mécanisme similaire aux précédents.
Peu de doc, très technique, lié à Solaris.
SSO local. Implémenté sous forme de servlets. A priori, s'appuie nécessairement sur kerberos. Propose un module apache.
http://filebox.vt.edu/users/clajoie/i2m/webiso/
SSO local. Implémentation qui tente d'adhérer aux recommandations WebISO, porposé sous forme de servlets.
Il propose un mécanisme de redirections entre le client web , l'application web et le service authPortal.
entre les 2, il implément le 'stub authportal' qui est du code ajouté à l'appli web, utilisé en cas de défaillance du serveur authPortal. Il permet de rediriger la demande d'authentification vers un autre serveur ou mécanisme d'authentification.
Le client est identifié par le serveur authPortal grâce à une cookie.
Un 'ticket' transmis par le serveur authPortal vers l'application permet de valider son authentification. Ce ticket est valable pour une application et un laps de temps donné.
http://www.washington.edu/pubcookie
SSO local. Bien documenté. Limité à l'authentification. Solution mure. Développée sous forme de cgi, en langage C. Supporte kerberos V5, ldap, shadow UNIX, ...
Notions de 'User Agent' (le navigateur du client), 'Application Server' (l'appli web), 'Login Serveur' (l'interface W3 gérant l'authentification web) et 'AuthN Service' (le service d'authentification interne).
Le 'login server' interagit directement avec le client web.
Il utilise 3 cookies :
le 'login cookie' : utilisé pour identifier l'utilisateur pour le 'login server' (equivalent JAG).
le 'session cookie' : utilisé par l'appli web pour sa session interne.
le 'granting cookie' : un cookie à durée de vie très limité, public, utilisé en jeton d'authentification pour une appli (equivalent JAA).
time outs :
login : intervalle pour forcer une ré authentification = 8 heures. Basé sur timestamp dans le 'login cookie'. scope = 'login server'.
application : intervalle pour rediriger à nouveau vers 'login server'. Basé sur inactivité ou 'hard timeout'. Défaut = 30 mn. Défaut hard = 8 heures. scope = 'application server'.
granting : 10 secondes. C'est le jeton à destination de l'application. scope = domaine de l'Université
Fournit un module apache (mod_pubcookie) pour permettre une authentification apache compatible pubcookie. Enrichi la variable d'environnement 'REMOTE_USER', accessible aux applis web.
authentification utilisateurs
gestion de session d'applications, avec gestion d'inactivité et timeouts hard
logoff applications
loging
http://www.cwl.ubc.ca/ (University of British Columbia)
Le document CWL API détaille l'API, et surtout décrit le mécanisme; très intéressant.
SSO local. Traite l'authentication et l'autorisation.
A priori, la solution dérive de
CAS.
Propose une API en java perl, C. Propose également un accès
via services web (XML + soap)
Gère, pour la partie autorisation,
une notion de role.
Un rôle est de la forme : ca.ubc.person.* pour une personne, ca.ucb.*
pour toute l'Université, ca.ucb.UnDepartement.* pour un département,
ca.ubc.CWLManagement.* pour le management CWL.
C'est finalement une notion de groupe.
Semble intégré dans uPortal
SSO inter établissement (uniquement). implémenté sous forme de servlets. Il traite à la fois l'authentification et la possibilité de transmettre des attributs liés à la personne authentifiée.
La technique proposée est complexe, en version béta pour
le moment. A voir à :
http://middleware.internet2.edu/shibboleth/
A voir également le document suivant qui décrit d'une manière très globale la technique.
Elle s'appuie sur la mise en oeuvre d'un
schéma ldap
compatible avec celui proposé par educause :
http://www.educause.edu/eduperson/
On peut regretter que le mécanisme s'intéresse uniquement aux échanges inter - établissement, sans s'intéresser aux échanges à l'intérieur de l'établissement entre les applications et le mécanisme d'authentification.
Voir http://araas.sourceforge.net/
Propose un mécanisme de SSO qui
traite l'authentication et
l'autorisation.
Propose un module apache.
peu de doc, projet à priori débutant.
A priori, SSO intra et inter établissement. Développé en perl.
voir http://www.rediris.es/app/papi/index.en.html
S'appuie sur deux éléments : le Serveur d'Authentification (AS) et le Point d'Accès PoA.
L'AS gère le mécanisme d'authentification, et délivre au navigateur client une liste d'URLs d'applications accessibles (en fonction de ses droits). Une durée spécifique est associée à chaque appli. Cette liste est signée avec la clé privée de l'AS.
Le PoA gère le controle d'accès pour un ensemble d'applications autorisées de l'établissement. si j'ai bien compris (??), il fait office de proxy web, toute requête vers une appli lui est adressée.
pas tout compris, la documentation est incomplète.
C'est un projet qui propose des techniques de SSO et d'authentification. Il propose des documents très intéressants.
La racine du site : http://www.projectliberty.org/
Une doc intéressante : http://www.projectliberty.org/specs/v1_1draft/draft-liberty-architecture-overview-v1.1-05.pdf
Voir en particulier le paragraphe 5.
La section 5.5 décrit une méthode pour du SSO inter-établissement,
basée sur un domaine DNS commun aux services d'authorité de certification.
SAML est un protocole permettant l'échange
d'informations d'authentification et d'habilitation via des flux XML (à la
façon de services web).
Il n'est pas encore reconnu comme un standard, mais on peut penser qu'il le
deviendra.
Un projet opensource est en cours afin d'apporter des libraires java et C++
simplifiant son usage : opensaml; ce projet est
maintenu par les développeurs de shibboleth
Voir cette page d'info sur SAML
Voir également http://www.oasis-open.org/
Et des choses qui n'ont rien à voir : kerberos et win2000 :
| Création : 12 mars 2003 - Vincent Mathieu (Université de Nancy 2), Julien Marchal (Université de Nancy 2) | |
|
Modifications : |