Propositions de mécanisme de SSO dans un environnement d’applications web

1. Propositions de mécanisme de SSO dans un environnement d’applications web Université Nancy 2 - CRI

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

3. Plan • Etat des lieux • Existant • Besoins • Pré-requis • Propositions (3 scénarios) • Extensions souhaitables • Démo

4. Etat des lieuxSituation 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, …)

5. Etat des lieuxBesoins • Eviter les ré-authentifications • Indépendance des applis par rapport aux mécanismes d’authentification • Délégation d’authentification

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

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

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 leJAG (Jeton d’Authentification Global) • Le JAG est porté par un cookie • Sessions applicatives

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

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

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

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

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. Scénario 1: dialogue appli - SAW Jeton d’Authentif. D’Appli (JAA) et Jeton Global (JAG) passés en service web Envoi Login / mot de passe authentification Saisie Login / mot de passe Premier accès Pas de JAG Jeton d’Authentif. D’Appli (JAA) retourné en service web Contrôle JAG Page Web en retour Et JAG en cookie Accès vers autre appli JAG présent Page Web en retour Service d’Authentification Web Base d’authentification Appli 1 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 Navigateur Web Appli 2

15. Impossibilité du scénario 1 • JAG peut être volé très facilement • Saisie login/mot de passe à charge de l’appli

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. Scénario 2 : redirections http authentification Redirection Post ou GET Passage de paramètres Pas de JAG Premier accès : Pas de session interne Jeton d’Authentif. D’appli (JAA) Passé en champ de formulaire Jeton D’Authentif Global (JAG) Passé en cookie privé Saisie Login/mot de passe Jeton d’Authentif. D’appli (JAA) Passé en formulaire Redirection Post ou Get Passage de paramètres JAG présent Redirection vers l’appli Avec le JAA Accès vers autre appli Page web En retour Redirection vers l’appli Avec le JAA Page web En retour Service d’Authentification Web Base d’authentification Appli 1 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 Navigateur Web Appli 2

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. Scénario 3 : JAA non renouvelable Redirection Post ou Get Passage de paramètres JAG présent Demande de paramètres et de validation du JAA (SAML?) Passage du JAA Accès vers autre appli JAA validé Et paramètres transmis (SAML?) Page Web en retour Redirection vers l’appli Avec le JAA Service Web d’Authentification Base d’authentification 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 Appli 1 Navigateur Web Appli 2

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

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