Principes de fonctionnement de l’authentification

Par rapport à la version 2, les changements sont importants: le portail Vulture est une application indépendante permettant de disposer d’un environnement autonome dédié à la personnalisation du parcours des utilisateurs lors de l’authentification.

Le workflow général de Vulture pour l’authentification est le suivant:

  1. L’utilisateur demande une ressource
  2. mod_vulture vérifie si l’utilisateur dispose d’un cookie pour cette application
  3. Si l’utilisateur dispose d’un cookie valide sur l’application demandée
    1. Si l’utilisateur dispose d’un cookie valide sur l’application demandée
    2. Si l’utilisateur est authentifié, Vulture donne accès à la ressource
  4. Si l’utilisateur ne dispose pas de cookie valide sur l’application demandée
    1. Si l’application n’impose pas d’authentification, Vulture fourni un cookie ‘anonyme’ et redirige l’utilisateur (HTTP 302) vers l’étape 1
    2. Si l’application exige une authentification, Vulture fourni un cookie ‘anonyme’ et redirige l’utilisateur vers le portail d’authentification
  5. Si Vulture ne trouve pas de session correspondante au cookie reçu, il détruit ce cookie et génère une nouvelle Session

fonctionnement-authentification

Ce workflow est assuré par le module « mod_Vulture ». Ce module Apache intervient très tôt dans le traitement de la requête: Il est exécuté pendant le traitement des headers, juste après l’exécution des modules mod_access et mod_rewrite.

Pourquoi délivrer un cookie anonyme aux utilisateurs, même si l’application protégée n’impose pas d’authentification ? Pour suivre le nombre de sessions anonymes (statistiques) et pour tracer l’activité des utilisateurs, ceci afin de détecter des anomalies comportementales (plus d’info à venir sur ce sujet).

Portail d’authentification

Lorsque mod_vulture décide qu’une requête doit être authentifiée, il redirige l’utilisateur vers le portail. Le portail pouvant se trouver sur un autre domaine que l’application protégée, il n’est pas possible de communiquer une session via un cookie: Vulture utilise donc un token temporaire véhiculé dans l’URL, lors de la redirection vers le portail.

Grâce à ce token, le portail retrouve la session anonyme dans Redis et sait quelle était l’application demandée par l’utilisateur. Il peut donc retrouver le repository sur lequel valider l’authentification. Lorsque les identifiants fournis par l’utilisateur sont corrects, le portail va charger les ACL et les comparer avec les droits de l’utilisateur. Si l’utilisateur a accès à la ressource, alors:

  • Vulture détruit le Token unique
  • Vulture met à jour la session applicative dans Redis (l’utilisateur n’est plus « Anonyme », mais « authentifié »)
  • Vulture fournit à l’utilisateur un Cookie Portail pour que l’utilisateur n’ai plus à saisir d’identifiant s’il se présente à nouvau devant le portail pour accéder à une autre application (il faut que cette application partage le même entrepôt d’authentification, sinon Vulture demandera à l’utilisateur de s’authentifier à nouveau) Une fois l’utilisateur authentifié, Vulture le redirige par défaut vers l’URL initialement demandée.

Plus d’informations sur l’authentification des utilisateurs