Post on 03-Apr-2015
Propositions de mécanisme de SSO dans un environnement
d’applications web
Université Nancy 2 - CRI
04/12/2002 - Proposition d'un mécanisme de SSO
2
Préalable
• Pas une solution, mais une réflexion
• Simpliste, démarche générale
• Pas mis en oeuvre
• Inspiré de mécanismes existants
04/12/2002 - Proposition d'un mécanisme de SSO
3
Plan
• Etat des lieux– Existant– Besoins
• Pré-requis
• Propositions (3 scénarios)
• Extensions souhaitables
• Démo
04/12/2002 - Proposition d'un mécanisme de SSO
4
Etat des lieux
Situation actuelle• Existant :
– Un compte unique pour un utilisateur– Ré-authentifications successives
• Limites– Sécurité du mot de passe -> https?– Traçabilité– Evolutions difficiles (certificats de personnes, …)
04/12/2002 - Proposition d'un mécanisme de SSO
5
Etat des lieux
Besoins
• Eviter les ré-authentifications
• Indépendance des applis par rapport aux mécanismes d’authentification
• Délégation d’authentification
04/12/2002 - Proposition d'un mécanisme de SSO
6
Contraintes
• Compatibilité avec navigateurs standards
• Sécurisation des échanges de mot de passe
• Indépendance pas rapport aux mécanismes internes d’authentification
• Extension à un mécanisme inter-établissement
04/12/2002 - Proposition d'un mécanisme de SSO
7
Propositions
• Points communs aux 3 scénarios proposés
• Scénario 1 : communication directe appli – serveur d’authentification
• Scénario 2 : le navigateur web sert de transport à la communication
• Scénario 3 : amélioration du scénario 2
• Passage du mot de passe aux applications
04/12/2002 - Proposition d'un mécanisme de SSO
8
Points communs aux propositions
• Un serveur Web dédié à l’authentification : SAW (Service d’Authentification Web)
• Un ticket d’authentification : JAA (Jeton d’Authentification Applicatif)
• Une session SAW portée par le JAG (Jeton d’Authentification Global)
• Le JAG est porté par un cookie• Sessions applicatives
04/12/2002 - Proposition d'un mécanisme de SSO
9
SAW : Service d’Authentif. Web
• Un serveur web dédié, accessible en https
• Lui seul fait appel au(x) mécanisme(s) d’authentification de l’Université (proxy)
• Génère le JAA pour les applis
• Gère des sessions pour éviter ré-authentifications
• Dispose d’un couple clé privée/clé publique
04/12/2002 - Proposition d'un mécanisme de SSO
10
JAA (Jeton d’Authent. Applis)
• Authentifie une personne• Spécifique à une appli, et limité en temps
(quelques secondes)
• Contient différentes informations :l’uid, l’ID d’appli, un timestamp (validité du JAA), l’IP du client, le type d’authentif, la base utilisée, ..
• Le JAA est signé avec la clé privée du SAW
04/12/2002 - Proposition d'un mécanisme de SSO
11
JAG : ID de session SAW
• SAW doit gérer une session (mémoriser infos sur users préalablement authentifiés)
• Infos à conserver : l’uid, l’IP du client, un timestamp (validité de la session SAW), le type d’authentif, l’ID d’appli, la base utilisée, ..
• Durée de session et reconduction
• Id de session SAW (JAG) porté par cookie
04/12/2002 - Proposition d'un mécanisme de SSO
12
Problèmes à résoudre
• Communication applis – SAW
• Protection du mot de passe
• Comment transporter le JAG
• Sécurité, et vol possible du JAA ou JAG
04/12/2002 - Proposition d'un mécanisme de SSO
13
Scénario 1
• Communication directe appli – SAW
• Utilisation de ‘services web’?
• Le client Web n’a pas de communication directe avec le SAW
• JAG signé avec clé privée du SAW
14
04/12/2002 - Proposition d'un mécanisme de SSO
Scénario 1: dialogue appli - SAW
NavigateurWeb
Premier accèsPas de JAG
Appli 1
Serviced’Authentification
Web
Appli 2
Based’authentification
Saisie Login / mot de passe
EnvoiLogin / mot de passe
authentification
Jeton d’Authentif. D’Appli (JAA)retourné en service web
Page Web en retourEt JAG en cookie
Accès vers autre appliJAG présent
Contrôle JAG
Page Web en retour
Intérêts :
Authentification externalisée
Pas de rebonds du client Web
SAW ne communique qu’avec des applis et non des clients Web
Inconvénients :
Piratage du JAG
Cookie nécessaire
Login/password géré par les applis
Password pas nécessairement protégé en https
Jeton d’Authentif. D’Appli (JAA)et Jeton Global (JAG) passés en service web
04/12/2002 - Proposition d'un mécanisme de SSO
15
Impossibilité du scénario 1
• JAG peut être volé très facilement
• Saisie login/mot de passe à charge de l’appli
04/12/2002 - Proposition d'un mécanisme de SSO
16
Scénario 2 : redirections http
• Pas de communication directe appli – SAW
• Rebonds http (GET - POST ?)
• Interactions avec le client Web et SAW
• JAG est un cookie privé de SAW en https
17
04/12/2002 - Proposition d'un mécanisme de SSO
Scénario 2 : redirections http
NavigateurWeb
Appli 1
Serviced’Authentification
Web
Appli 2
Based’authentification
Intérêts :
Authentification externalisée
Simple
Password protégé en https
Login/password non géré par appli
Protection du JAG
Inconvénients :
Multiples redirections
Cookies / javascript nécessaire
Premier accès :Pas de session interne
Redirection Post ou GETPassage de paramètres
Pas de JAG
SaisieLogin/mot de passe
authentification
Jeton d’Authentif. D’appli (JAA)Passé en champ de formulaire
Jeton D’Authentif Global (JAG)Passé en cookie privé
Redirection vers l’appliAvec le JAA
Page webEn retour
Accès vers autre appli
Redirection Post ou GetPassage de paramètres
JAG présent
Jeton d’Authentif. D’appli (JAA)Passé en formulaire
Redirection vers l’appliAvec le JAA
Page webEn retour
04/12/2002 - Proposition d'un mécanisme de SSO
18
Scénario 3 : JAA non renouvelable
• Proche du scénario 2
• JAA non rejouable
• Communication directe Appli -> SAW après réception du JAA
• Permet la récupération d’infos annexes
• Apporte de la sécurité
19
04/12/2002 - Proposition d'un mécanisme de SSO
Scénario 3 : JAA non renouvelable
NavigateurWeb
Appli 1
Service Webd’Authentification
Appli 2
Based’authentification
Page Web en retourAccès vers autre appli
Redirection Post ou GetPassage de paramètres
JAG présent
Passage du JAA
Redirection vers l’appliAvec le JAA
Demande de paramètres et de validation du JAA
(SAML?)
JAA validéEt paramètres transmis
(SAML?)
Intérêts :
Mêmes que précédemment
JAA ne porte pas d’info
Meilleure sécurité
Protocole de transport d’infos
Inconvénients :
Plus complexe
04/12/2002 - Proposition d'un mécanisme de SSO
20
Extensions possibles
• A-t-on besoin du mot de passe?
• Traiter l’Autorisation (droits des applis)– Quelles infos nécessaires pour l’Autorisation ?– Autres infos utiles aux applis
• Restrictions d’accès par le serveur http
• Aspects inter-établissement– Groupe de travail à venir
04/12/2002 - Proposition d'un mécanisme de SSO
21
Conclusion
• Demo : http://cridev.univ-nancy2.fr:7999/PORTAIL/
• Voir les implémentations existantes
• Faire quelque chose de souple, évolutif
• Proposer un mécanisme général et des modules clients