djangosaml2 authenticates user but I get anonymous user in my view

user_1077102 0
Viewed 309

I am using djangosaml2 to authenticate my users. I've been using it for a long time now with no problem. I am currently in the process of upgrading Python and Django to newer versions and the authentication does not work anymore.

Using the logs, I see that the authentication in djangosaml2 is successful but in my view, the request.user is an anonymous user.

Here are the working and none-working library versions that I use:

  • Python: 2.7 --> 3.8
  • Django: 1.9 --> 1.11
  • djangosaml2: 0.17.2 (in both evns.)
  • pysaml2: 4.0.5 --> 6.5.1 (tested also with 4.0.5)

Additional Info:

I see that the call to /saml2/acs/ redirects to / (access to my site) and the response includes the session_id.

The next HTTP call - to / - includes the received session_id.

However, in the Database I do not see this session id. As the session id is not found in the Dbase, it is indeed considered as anonymous.

Why is the session id is not stored?

django-saml2-auth saml-2.0 django python
1 Answers

The problem arises as in saml2 I deleted the user's pwd in my post authenticate method (for some other reason). This PWD is not something the user is aware of and as such, no harm was done.

Turns out that the library creates a password that is used for calculating the session hash code even though the user itself is not aware of this PWD.

The session hash is calculated with this PWD. when compared with the calculated hash (based on the user's deleted PWD) the result is False - causing the session to be flushed (and as there is no session, the user is anonymous)

This behavior is not new. Why did it work before, then?

In older Django versions, the get_user (in contrib.auth.init) used to check the hash with the following condition:

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

Since the SessionAuthenticationMiddleware was not set, this condition is not met and the hash was not checked.

In newer versions this middleware is deprecated and the new get_user condition is only the second one:

if hasattr(user, 'get_session_auth_hash'):

Causing the session verification to check the hash and fail.

I changed my post authentication method to not delete the pwd and all works now.

user_10771020
Related