Si vous avez déjà installé Alfresco 3.0, vous vous êtes sûrement rendu compte que les deux applications Share et Alfresco gèrent leur authentification indépendamment l’une de l’autre. Si vous passez de Share à Alfresco (et inversement), vous devez de nouveau montrer patte blanche en donnant votre nom d’utilisateur et votre mot de passe … ce qui est particulièrement frustrant pour nos utilisateurs. Que faire ? Mettre en place un système de SSO et CAS répond très bien à ce problème.

# Principes d’authentification de Share et de CAS

Je ne vais pas revenir sur l’installation et la configuration d’un serveur CAS. Ceci n’est pas l’objet de ce billet. Nous verrons uniquement comment CASifier Share (ce qui va déjà nous occuper un petit moment).

Je vais revenir rapidement sur le principe d’authentification de Share pour bien exposer le problème :

  • l’utilisateur ouvre l’application Share
  • Share affiche la page de login
  • l’utilisateur envoie le couple login / mot de passe
  • ce couple est envoyé vers un webscript Alfresco par Share
  • si Alfresco valide le couple, il renvoie un ticket
  • Share utilisera ce ticket pour toutes les futures communications avec Alfresco

Ceci montre que le mot de passe donné sur la page de login de Share est ensuite envoyé à Alfresco. C’est la réponse d’Alfresco qui conditionne l’accès (ou non) à l’application Share.

Une application CASifiée utilise le principe suivant pour authentifier un utilisateur :

  • connexion de l’utilisateur à l’application (il n’a pas encore de ticket CAS valide)
  • l’application le renvoie vers la page de login de CAS
  • l’utilisateur envoie le couple login / mot de passe à CAS
  • ce couple est validé par le backend de CAS
  • si le couple est valide, CAS redirige l’utilisateur vers l’application accompagné d’un ticket ST (Service cket)
  • l’application valide le ticket ST auprès de CAS et récupère le login de l’utilisateur
  • l’application authentifie l’utilisateur uniquement sur le login

De ces deux procédures d’authentification, on peut déjà faire ressortir le principale problème : l’application CASifiée ne voit jamais le mot de passe de l’utilisateur. Dans ce cas comment Share peut-il envoyer le couple login / mot de passe à Alfresco ?

# Quelles sont les solutions ?

Une première piste serait d’utiliser notre ticket ST dans Share et l’envoyer à la place du mot de passer à Alfresco. Il faudrait réaliser des modifications côté Alfresco pour valider ce ticket ST auprès du serveur CAS. Cependant, cela ne peut fonctionner car un ticket ST est à usage unique. Il est invalidé côté CAS après la validation de Share, il ne peut donc plus être utilisé par Alfresco.

La seconde piste (qui sera la bonne) est l’utilisation d’un Proxy Ticket (PT). Le système de proxy a été introduit dans CAS 2, il faudra donc utiliser un serveur et un client supportant cette architecture.
Si on reprend la procédure d’authentification de CAS avec l’utilisation d’un PT, cela devient :

  • connexion de l’utilisateur à Share (il n’a pas encore de ticket CAS valide)
  • Share le renvoie vers la page de login de CAS
  • l’utilisateur envoie le couple login / mot de passe à CAS
  • ce couple est validé par le backend de CAS
  • si le couple est valide, CAS redirige l’utilisateur vers Share accompagné d’un ticket ST (Service Ticket)
  • Share valide le ticket ST auprès de CAS et demande un PGT (Proxy Granting Ticket)
  • CAS renvoie le login de l’utilisateur et un PGT
  • Share demande un PT (Proxy Ticket) à CAS à l’aide du PGT
  • CAS renvoie le PT
  • Share envoie le PT à Alfresco via un webscript
  • Alfresco valide le PT via CAS et récupère le login
  • Alfresco crée un ticket (un ticket Alfresco, pas un ticket CAS) et le renvoie à Share pour les futures échanges

Ouf ! C’est un peu long, mais ça fonctionne et c’est totalement transparent pour les utilisateurs.
Bon, on a un principe qui est fonctionnel, il ne nous reste plus qu’à passer au plus intéressant : la réalisation.

# En pratique…

En pratique, il faut modifier Share et Alfreso. Des modifications des deux côtés sont nécessaires pour mettre en place le SSO. Les modifications se résument à quelques fichiers Java et beaucoup de XML.

# Côté Share

  • web.xml : ajouter les filtres pour CAS
  • webscript-framework-config.xml : modification de classe d’authentification (envoie du PT à la place du mot de passe sur un nouveau webscript)
  • ajouter le jar du client CAS
  • ajouter deux nouvelles classes Java :
    • CasAuthenticationFilter : valide le ST, récupère le PT et authentifie l’utisateur dans Share
    • CasAlfrescoAuthenticator : envoie le PT vers un webscript Alfresco et récupère un ticket Alfresco

# Côté Alfresco

  • web.xml : ajouter les filtres pour CAS
  • ajouter le jar du client CAS
  • ajouter le webscript recevant le PT de Share
  • ajouter la classe Java pour l’authentification CAS classique

# Le code

Ces deux archives contiennent tout le code et les modifications nécessaires pour mettre en place un SSO basé sur CAS entre Share et Alfresco. Avant d’utiliser ces fichiers, il faut les modifier pour correspondre à votre installation (notamment les adresses des serveurs CAS et Alfresco).

Tweetez
Partagez
Partagez
0 Partages