djangosaml2 authentifie l'utilisateur mais j'obtiens un utilisateur anonyme dans ma vue django

Question

J'utilise djangosaml2 pour authentifier mes utilisateurs. Je l'utilise depuis longtemps maintenant sans problème. Je suis actuellement en train de mettre à jour python et django vers des versions plus récentes et l'authentification ne fonctionne plus. En utilisant les logs, je vois que l'authentification dans djangosaml2 est réussie mais dans ma vue, la requête.user est un utilisateur anonyme.

Voici les versions de la librairie qui fonctionnent et celles qui ne fonctionnent pas que j'utilise :

Python : 2.7 --> 3.8

Django : 1.9 --> 1.11

djangosaml2 : 0.17.2 (dans les deux evns.)

pysaml2 : 4.0.5 --> 6.5.1 (testé aussi avec 4.0.5)

Informations supplémentaires :

je vois que l'appel à /saml2/acs/ redirige vers "/" (accès à mon site) et la réponse inclut le session_id.

L'appel http suivant - vers "/" - inclut le numéro de session reçu.

Cependant Dans la base de données, je ne vois pas cet identifiant de session. Comme l'id de session n'est pas trouvé dans la Dbase, il est en effet considéré comme anonyme.

Une idée de la raison pour laquelle l'identifiant de session n'est pas stocké ?

Answer 1

Ok, enfin, j'ai une solution !

Le problème vient du fait que dans saml2 j'ai supprimé le pwd de l'utilisateur dans ma méthode post authenticate (pour une autre raison). Ce pwd n'est pas quelque chose dont l'utilisateur est conscient et en tant que tel, aucun mal n'a été fait. Il s'avère que la bibliothèque crée un mot de passe qui est utilisé pour calculer le code de hachage de la session même si l'utilisateur lui-même n'a pas connaissance de ce pwd. Le code de hachage de la session est calculé avec ce mot de passe. Lorsqu'il est comparé au code de hachage calculé (basé sur le mot de passe supprimé de l'utilisateur), le résultat est Faux, ce qui entraîne la suppression de la session (et comme il n'y a pas de session, l'utilisateur est anonyme).

Ce comportement n'est pas nouveau. Pourquoi cela fonctionnait-il avant, alors ?

Dans les anciennes versions de django, la fonction get_user (dans contrib.auth.init) avait l'habitude de vérifier le hachage avec la condition suivante :

if ('django.contrib.auth.middleware.SessionAuthenticationMiddleware'
                in settings.MIDDLEWARE_CLASSES and 
                hasattr(user, 'get_session_auth_hash')):

Comme 'SessionAuthenticationMiddleware' n'a pas été défini, cette condition n'est pas remplie et le hachage n'a pas été vérifié.

Dans les versions plus récentes, cet intergiciel est déprécié et la nouvelle condition get_user n'est que la deuxième :

        if hasattr(user, 'get_session_auth_hash'):

Ce qui fait que la vérification de la session vérifie le hachage et échoue.

J'ai changé la méthode d'authentification de mon poste pour ne pas supprimer le pwd et tout fonctionne maintenant.