Groupe 1B (SSO et gestion des autorisations)
Date de création :	12 mai 2003
Dernière modification :
Diffusion :	internet

Retour des représentants de ESUP-Portail au groupe AAS après la réunion du 7 mai 2003

Bonjour,

Suite à notre dernière réunion, nous avons eu l'impression d'une certaine incompréhension quant au fonctionnement du CAS. De notre part, certains sujets abordés lors de la réunion nous semblent mériter précisions.

Nous vous joignons donc ce document, qui tente d'expliquer simplement le mécanisme de SSO du CAS, et qui résume les principales interrogations que nous avons.
Nous pouvons rendre disponible une maquette de démonstration si nécessaire.

• le fonctionnement global de CAS
• le choix de CAS (impératifs de sécurité, motivations)
• ce que nous croyons comprendre à la problématique d'inter-opérabilité

• nos inquiétudes par rapport aux recommandations à venir

• En annexe, la cinématique de CAS

Le fonctionnement global de CAS

Une présentation technique du fonctionnement de CAS est disponible à l'URL suivante :
http://perso.ifsic.univ-rennes1.fr/aubry/doc/esup/SSO_1B/cas/index.html.

En particulier, une présentation PowerPoint présente la cinématique de CAS.

Une annexe à ce document décrit d'une manière succincte cette cinématique.

D'une manière générale :

CAS ne traite que la partie authentification. Le serveur CAS est accessible en http et/ou https sur différentes URL. Le navigateur de l'utilisateur doit pouvoir y accéder en https ; les applications utilisatrices ont également des accès directs en http(s) vers ce serveur.

Les applications utilisatrices, y compris le portail, n'ont jamais connaissance du mot de passe. Les applications doivent acquérir un 'ticket opaque' auprès du serveur CAS ; ce ticket ne transporte aucune information et n'est jouable qu'une seule fois. Il permet à l'application d'acquérir ensuite l'identification de l'utilisateur certifiée.

Fonctionnement 'de base'

Les applications utilisatrices de ce mécanisme de SSO se comportent systématiquement de la manière suivante (y compris le portail) :

Lors de l'accès à l'application, celle-ci redirige (redirection http) automatiquement ou après validation le navigateur du client vers le serveur CAS, en https.

• Si l'utilisateur n'a pas de 'session serveur CAS', le serveur CAS fait apparaître une fenêtre d'authentification, puis controle le couple login/mot de passe auprès du mécanisme local d'authentification (LDAP en l'occurence).
  Si l'authentification est réussie, le serveur CAS redirige automatiquement le navigateur vers l'application demandeuse, en lui passant un ticket (ST : Service Ticket). Il génère également une 'session CAS' (en fait, un cookie privé et protégé), afin d'éviter les ré authentifications successives.
• Si l'utisateur a une 'session serveur CAS' active, il est redirigé automatiquement vers l'application demandeuse avec le ticket ; dans ce cas, la récupération du ticket (donc 2 redirections http(s) successives du navigateur) s'est passée de manière entièrement transparente à l'utilisateur.

L'application dispose maintenant du ticket, valide pour un utilisateur, une application, un 'certain temps' très court, et une seule utilisation. Elle génère alors une connexion http directe auprès du serveur CAS en lui passant le ticket en paramètre du GET ; le serveur CAS vérifie ce ticket, l'invalide en interne, et retourne dans le corps du message http en xml une seule information : l'identité de l'utilisateur. Cette connexion est bien sûr invisible pour l'utilisateur.

Fonctionnement multi-tiers

C'est par exemple le portail, qui fait appel à un 'service web'. Dans ce cas, le navigateur de l'utilisateur n'a pas de contact http direct avec ce service web ; le schéma précédent n'est donc plus valide.
Le mécanisme CAS a prévu cette éventualité ; une telle application peut devenir 'proxy CAS' : lors du mécanisme précédent, à la place du Service Ticket, cette application (le portail dans l'exemple) reçoit d'une manière sécurisée un jeton particulier (PGT : Proxy Granting Ticket), qui est rejouable et à durée de vie plus longue (quelques heures). Ce jeton va permettre au portail de demander autant de fois que nécessaire, directement en https (ce n'est pas le navigateur, mais l'application) un ticket (PT : Proxy Ticket) qu'il pourra passer au(x) service(s) tiers. Le service tiers pourra alors contacter le serveur CAS en http directement de la même façon que dans le fonctionnement de base ; le serveur CAS vérifie ce ticket, l'invalide en interne, et retourne dans le corps du message http une seule information : l'identité de l'utilisateur.

Remarque

Le fait de ne pas disposer du mot de passe nous pose quelques soucis pour traiter les accès IMAP (serveur de messagerie).
Des essais sont en cours afin de valider (on non) la possibilité de rendre IMAP compatible avec le mécanisme CAS.

Motivations du choix de CAS

Impératifs de sécurité

Les impératifs de sécurité fixés par le groupe de travail SSO du projet eSup-Portail sont les suivants :

• Le mot de passe des utilisateurs ne doit jamais circuler en clair.
• Il ne doit pas être mémorisé.
• Les données permettant d'obtenir un jeton sont protégées, ou non rejouables.

Pour information : le document suivant, communiqué par Olivier Salaun décrit les différentes méthodes de délégation de privilège en environnement N-Tier et évalue le niveau de sécurité associé (CAS se situe dans le choix 1.3.4).

Motivations du choix de CAS

Ci-dessous les différences relevées entre les schémas de fonctionnement proposés lors de notre réunion du 7 mai et le fonctionnement de CAS.

Le serveur d'authentification est dissocié du portail ?

• Toute la sécurité est centralisée sur un serveur dédié.

• Les applications sont autonomes vis-à-vis du portail. Entre autres avantages, ça permet d'envisager une montée en charge du portail progressive, les applications 'externes' pouvant être utilisées sans être connu du portail.

Le mot de passe ne circule pas par le portail

• L'accès au portail n'a pas nécessairement besoin d'être sécurisé (à voir selon la confidentialité des données circulant pendant les transactions ).

• Le développement d'applications et/ou de canaux du portail peut être délégué (si le mot de passe circule sur le portail, tout exécutable sur le portail peut potentiellement le pirater).

Le mot de passe n'est pas transmis aux applications

• Il n'est pas nécessaire de chiffrer tous les accès aux applications (depuis le navigateur et depuis le portail). Il n'y a pas nécessité d'être dans un espace de confiance entre le portail et les applications / services web utilisés.

• On évite un grand risque de compromission dans un contexte de Single Password (le mot de passe est rejouable, chiffré ou non).

• Il n'est de toutes façons pas raisonnable de transmettre un mot de passe aux applications (authentification sur certificat X509 notamment).

Le fonctionnement en mode super-utilisateur du portail vers les applications n'est pas satisfaisant

• Il s'agit d'une concession supplémentaire en terme de sécurité (autorisation d'un accès privilégié depuis le portail, parfois avec stockage permanent d'un login/password).

• Le super-utilisateur n'a pas forcément le même rôle que l'utilisateur authentifié (en particulier pour le protocole IMAP, les courriers lus comme super-utilisateur ne seront pas marqués comme lus par l'utilisateur réellement authentifié).

Nous préférons un accès au serveur d'autorisations depuis les applications

• Le portail n'a ainsi pas besoin de connaître les besoins des applications ; la centralisation de la politique d'accès aux données potentiellement confidentielles est déportée sur le serveur d'autorisations.

• On peut espérer du serveur d'autorisation une grande finesse dans le dialogue avec les applications, d'un autre niveau que "X est-il un enseignant ou un étudiant ?". Par exemple des requêtes s'appuyant sur d'autres sources de données que l'annuaire LDAP telles :
  • X enseigne-t-il dans la matière Y?
  • X est-il affecté à un poste de la section CNU S
  • quels sont les étapes Apogée dans lesquelles X a le droit de modifier l'offre de formation d'au moins une matière ?

  Pour des requêtes de ce type, on ne pourra a priori prévoir toutes les informations que le portail devra fournir aux applications, et un retour vers le serveur d'autorisation sera de toutes façons nécessaire.

• Les applications sont sont pas tributaires du portail dans leur fonctionnement.

Problématique d'inter-opérabilité

Schéma retenu

Est-ce que le schéma proposé par Jean-Paul lors de la réunion est bien la cible visée ? A savoir :
L'utilisateur Rennais qui voudrait accéder à une application située à Nancy se logue dans le serveur d'authentification / autorisation de Rennes pour accéder à cette application.

Ce fonctionnement nous paraît tout à fait logique, mais il est important de le préciser.

Utilisation de SAML

Tous les participants du groupe de travail ont été d'accord pout l'utilisation de SAML, en particulier pour traiter le problème d'inter opérabilité.

Question : SAML nécessite-t-il d'être dans un espace de confiance entre les 'socles' et les applis? SAML n'est-il utilisé que pour permettre la propagation des identités / profils, ou alors sert-il également à l'authentification auprès de l'application?
Si on est dans un espace de confiance, on peut supposer que la propagation de l'identité d'un socle vers une appli vaut authentification ; est-ce bien celà ce qu'il faut comprendre ?

Inquiétudes

Nos inquiétudes concernent principalement les problèmes d'inter-opérabilité (CAS semble donner toute satisfaction dans un contexte de SSO intra établissement). Dans notre fonctionnement, les applications doivent nécessairement être adaptées à CAS pour l'aspect authentification : elle ne reçoivent qu'un jeton qui ne contient aucune information.

Si le schéma d'inter opérabilité est celui décrit précédemment, nous ne voyons pas comment le traiter avec le mécanisme choisi. Faut-il donc remettre en cause ce choix?

Création : 12 mai 2003 - Pascal Aubry (Univeristé de Rennes 1), Vincent Mathieu (Université de Nancy 2)
Modifications :