Empêcher l'authentification d'un membre JCMS avec un AuthenticationHandler

Salut Olivier,

Merci beaucoup pour ta réponse. J'avais pourtant fait des recherche sur le forum, mais je n'avais pas trouvé cette discussion qui répond effectivement à mon besoin.

Au début, en te lisant, j'imaginais me brancher plutôt après le SessionAuthenticationHandler, car j'avais peur que mon WebService d'authentification soit appelé plusieurs fois par session. Mais en fait, en y réfléchissant, mon AuthenticationHandler commence par tester s'il a des crendentials fournis et sinon, il appel directement doChain() et fait un return. Je peux donc me permettre de me positionner au début de la chaîne, de toute façon mon WebService ne sera appelé que lorsqu'un formulaire de login sera soumis par l'utilisateur...

J'ai bon, non ?

Petite note d'après mon expérience du jour...

J'appel mon AuthenticationHandler custom en début de chaîne, celui-ci commence par vérifier qu'on a pas déjà un membre connecté et qu'en plus des credentials sont fournis. Car le but de mon AuthenticationHandler est d’intercepter le login/password saisi par l'utilisateur dans la page ou une portlet de login JCMS, soumettre ces éléments à un WebService, puis faire un setLoggedMember et continuer la chaîne d'authentification si le WebService valide les credentials fournis ou au contraire stopper la chaîne sans rien faire si le WebService ne valide pas.

Jusqu'ici tout va bien, techniquement ça marche et, dans les cas nominaux l'utilisateur se retrouve effectivement authentifié sur JCMS.

Là où j'ai eu une expérience un peu bizarre, c'est qu'en bout de course l'utilisateur se retrouve à chaque fois sur la page de login par défaut du front JCMS. Et, cerise sur la bizarrerie, quand l'utilisateur navigue à ce stade, par exemple en cliquant sur un lien de retour à l'accueil, il se retrouve effectivement authentifié. Ce passage par la page de login parait donc injustifié. Et puis en plus j'imaginais que la page de login redirigeait forcément sur la page d'accueil à partir du moment où l'utilisateur était déjà identifié... Bref, c'est bizarre.

J'ai testé un truc qui a fini par me faire retomber sur mes pattes : juste après avoir fait un setLoggedMember, je fait un sendRedirect vers l'accueil. Et là... Oh magie ! Ça marche et l'utilisateur est bien authentifié.

J'en arrive à me dire que, peut-être, tout ou partie de la mécanique de redirection des pages de login est tributaire d'un éventuel passage par le SimpleAuthenticationHandler qui, peut-être, ne fait rien à partir du moment où il voit qu'il y a déjà un membre authentifié en amont dans la chaîne.

Qu'en pensez-vous ? Est-ce que mon hypothèse est totalement débile où est-ce qu'il y a de ça ? Est-ce juste un passage obligé quand on fait un AuthenticationHandler qui exploite des credentials fournis par un formulaire de login standard de réimplémenter une mécanique de redirect ?

Merci Olivier de confirmer mon hypothèse et de me fournir le code nécessaire pour réimplémenter la redirection normalement effectuée par le SimpleAuthenticationHandler.

Pour le fait de désactiver les comptes, j'y avais pensé, mais ça va te paraître bête, je n'ai pas trouvé comment fonctionne la mécanique d'activation/désactivation de compte. Ou plutôt... Je pense avoir compris que c'est lié à un mot de passe particulier à mettre à la place de l'original. Sauf que, si c'est bien ça, je n'aime pas trop l'idée de ce que j'aurais à faire pour réactiver un compte. Il faudrait en fait que je fasse un setPassword du mot de passe saisi par l'utilisateur à partir du moment où mon WebService valide son authentification... Je ne trouve pas que ça soit spécialement plus propre que de simplement accepter son authentification. En tout cas je n'était pas à l'aise avec cette solution...

En effet pour désactiver un compte le code est le suivant :

Member mbrUpdated= (Member) member.getUpdateInstance()
mbrUpdated.disable(); // équivalent à update.setPassword(Member.DISABLED_PASSWORD);
mbrUpdated.performUpdate();

Et pour le réactiver il faut faire :

Member mbrUpdated= (Member) member.getUpdateInstance()
mbrUpdated.setPassword(channel.crypt(newPassword));
mbrUpdated.performUpdate();

Si tu fais entièrement confiance à ton WebServices et qu'il a validé l'authentification, cela me parait tout à fait correct de le réactiver à partir du mot de passe reçu.

Mais si tu ne compte pas autoriser l'authentification JCMS standard, tu peux même mettre un mot de passe généré aléatoirement, de cette façon le compte est actif, mais seul l'authentification via WebService est possible (ce qui est fait pour l'activation d'un compte LDAP, cf custom/LdapAuthenticationHandler.java). Il n'y a aucune possibilité que l'utilisateur puisse se connecté avec ce mot de passe généré aléatoirement qui n'est pas enregistré crypté, pas d'appel à channel.crypt(password), ce qui ne correspondra donc à aucune HASH de mot de passe valide.

   mbrUpdated.setPassword(PasswordGenerator.generateRandomPassword(8));