Propositions de m

1
Propositions de mécanisme de SSO dans un
environnement dapplications 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 -gt 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 dauthentification
• Délégation dauthentification

6
Contraintes

• Compatibilité avec navigateurs standards
• Sécurisation des échanges de mot de passe
• Indépendance pas rapport aux mécanismes internes
  dauthentification
• Extension à un mécanisme inter-établissement

7
Propositions

• Points communs aux 3 scénarios proposés
• Scénario 1 communication directe appli
  serveur dauthentification
• 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é à lauthentification
  SAW (Service dAuthentification Web)
• Un ticket dauthentification JAA (Jeton
  dAuthentification Applicatif)
• Une session SAW portée par le JAG (Jeton
  dAuthentification Global)
• Le JAG est porté par un cookie
• Sessions applicatives

9
SAW Service dAuthentif. Web

• Un serveur web dédié, accessible en https
• Lui seul fait appel au(x) mécanisme(s)
  dauthentification de lUniversité (proxy)
• Génère le JAA pour les applis
• Gère des sessions pour éviter ré-authentifications
  
• Dispose dun couple clé privée/clé publique

10
JAA (Jeton dAuthent. Applis)

• Authentifie une personne
• Spécifique à une appli, et limité en temps
  (quelques secondes)
• Contient différentes informations luid, lID
  dappli, un timestamp (validité du JAA), lIP du
  client, le type dauthentif, 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 luid, lIP du client, un
  timestamp (validité de la session SAW), le type
  dauthentif, lID dappli, 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 na pas de communication directe
  avec le SAW
• JAG signé avec clé privée du SAW

14
Scénario 1 dialogue appli - SAW
Service dAuthentification Web
Appli 1
Base dauthentification

• Intérêts
• Authentification externalisée
• Pas de rebonds du client Web
• SAW ne communique quavec 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 lappli

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
Service dAuthentification Web
Appli 1
Base dauthentification

• 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 -gt SAW après
  réception du JAA
• Permet la récupération dinfos annexes
• Apporte de la sécurité

19
Scénario 3 JAA non renouvelable
Service Web dAuthentification
Appli 1
Base dauthentification

• Intérêts
• Mêmes que précédemment
• JAA ne porte pas dinfo
• Meilleure sécurité
• Protocole de transport dinfos

• Inconvénients
• Plus complexe

Navigateur Web
Appli 2
20
Extensions possibles

• A-t-on besoin du mot de passe?
• Traiter lAutorisation (droits des applis)
• Quelles infos nécessaires pour lAutorisation ?
• Autres infos utiles aux applis
• Restrictions daccès par le serveur http
• Aspects inter-établissement
• Groupe de travail à venir

21
Conclusion

• Demo http//cridev.univ-nancy2.fr7999/PORTAIL/
• Voir les implémentations existantes
• Faire quelque chose de souple, évolutif
• Proposer un mécanisme général et des modules
  clients