snok/django-auth-adfs

ensure lowercase email as username; Azure AD upn appears to be case-sensitive

vanderzielj opened this issue · 5 comments

vanderzielj commented

Is there a way to ensure that the Azure AD upn (effectively an email address) is set to all lowercase before creating a new username with it? That is, I wish my Django implementation to use case-insensitive email addresses (stored as all lower-case) as usernames. I am wondering how best to achieve this useing django-auth-adfs.

Discovery

I am using the demo/adfs project pointing at my dev ADFS. I wanted to see how the User mapping worked with the django-auth-adfs add-on so I created a super user using justin.vanderziel@mycompany.com and tried to login but access was denied. So I tried to create a super user using Justin.VanderZiel@mycompany.com but the Django admin said that the user already existed! I modified the Django user created using the UPN to have the is_superuser flag using the Django Admin so I could see what was going on. It seems that I have two users created: one with a username of justin.vanderziel@mycompany.com and another with a username of Justin.VanderZiel@mycompany.com. Regardless of the case-sensitivity requirements of Azure AD for the UPNs I would like the case-insensitive UPN to be used as the username. In my main project I have created a customer user based on AbstractUser that uses the email address field type (presumably case-insensitive)

Upvote & Fund

  • We're using Polar.sh so you can upvote and help fund this issue.
  • We receive the funding once the issue is completed & confirmed by you.
  • Thank you in advance for helping prioritize & fund our backlog.
Fund with Polar
tim-schilling commented

This is something we're unlikely to change. I would recommend that you subclass the AdfsBaseBackend (or whichever backend you're using) and redefine the create_user function to your specifications.

  • 👍2
vanderzielj commented

I've seen read in other forums that it's best practice to respect the case of the email provider so I get that. I'll take a look at the links you provided.

JonasKs commented

Essentially Tim says you can do this:

class MyCustomAdfsAuthCodeBackend(AdfsAuthCodeBackend):
    def create_user(self, claims):
        # my custom implementation of create_user

And then where you use AdfsAuthCodeBackend, you use your own MyCustomAdfsAuthCodeBackend instead.

vanderzielj commented

Here's the (current) rub: I'm trying to authenticate against Azure Entra (AD). In your ADFS Config Guide for Azure AD you indicate that (only) the django_auth_adfs.backend.AdfsAccessTokenBackend is required in the AUTHENTICATION_BACKENDS. However, I get an inexplicable Login Failed error whenever I try to login if I remove the django_auth_adfs.backend.AdfsAuthCodeBackend from my list of AUTHENTICATION_BACKENDS. This is not a problem as it stands: I enable both and everything works. However, which backend would I have to customize? - both?

JonasKs commented

AdfsAccessTokenBackend is for rest API auth (using access tokens only). AdfsAuthCodeBackend is for Django auth, where you get redirected and the token is fetched by the Django backend. So if you don't use DRF, you probably don't need the AdfsAccessTokenBackend.

Anyway, yes, you would have to customize any backend you use.

  • 👍1