could we have USERNAME_CLAIM non-mandatory?

Question

could we have USERNAME_CLAIM non-mandatory?

cusco opened this issue 2 years ago · 6 comments

Hello, thanks for the great work on this plugin.

I'm attempting to integrate with AzureAD, and our django backend has some custom pattern for usernames, that won't match anything in Azure.
We'd like to use the email field to match Azure's UPN only, being that email is unique in our backend.

Do you think this makes sense and should be changed in the plugin?

Like a mandatory setting like UPN_CLAIM_MAPPING = 'email_field'

Answer 1 · 2022-11-17T14:00:27.000Z

Am I understanding you correctly that you'd like to key authentication based on the email rather than the username because the username in Django can't match what Azure would pass back?

If that's the case, would this new configuration only be usable if the setting to create users is disabled because a username can't be determined?

Answer 2 · 2022-11-17T14:23:28.000Z

Ah! I see your point. In our case we don’t want to create users, only to match existing. But I’m guessing upon creation it would either use the UPN..?

…

On Thu, 17 Nov 2022 at 14:00, Tim Schilling ***@***.***> wrote: Am I understanding you correctly that you'd like to key authentication based on the email rather than the username because the username in Django can't match what Azure would pass back. If that's the case, would this new configuration only be usable if the setting to create users is disabled because a username can't be determined? — Reply to this email directly, view it on GitHub <#263 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAW3L73GS4F77XOBCXVYNKDWIY3ANANCNFSM6AAAAAASDJRF5E> . You are receiving this because you authored the thread.Message ID: ***@***.***>

Answer 3 · 2022-11-17T14:30:45.000Z

I think I'd need to be convinced that this is an issue for more folks before agreeing that it's something that should be supported out of the box. Let's see what other maintainers think.

I'm happy to help with PRs that refactor the application to make it easier for you to implement this on your end. It's clearly a real possibility, but I think I'd prefer that you maintain it in your own project (with the information and understanding I have currently).

Answer 4 · 2022-11-17T19:36:46.000Z

Hmm, I'm not entirely sure I understand, so please clarify:

you already have the users
you don't want creation of new users
you want the user to log in through azure, but not really do anything with it, except match it towards an already existing user

?

Answer 5 · 2022-11-17T23:56:43.000Z

Yes! We onboard users manually in advance. Then organisations are able to use their own Azure AD as a SSO option.

…

On Thu, 17 Nov 2022 at 19:37, Jonas Krüger Svensson < ***@***.***> wrote: Hmm, I'm not entirely sure I understand, so please clarify: - you already have the users - you don't want creation of new users - you want the user to log in through azure, but not really do anything with it, except match it towards an already existing user ? — Reply to this email directly, view it on GitHub <#263 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAW3L77OP2F7CDJWIPH6SSLWI2CNRANCNFSM6AAAAAASDJRF5E> . You are receiving this because you authored the thread.Message ID: ***@***.***>

Answer 6 · 2022-11-18T17:51:28.000Z

I think I'd need to be convinced that this is an issue for more folks before agreeing that it's something that should be supported out of the box. Let's see what other maintainers think.

I'm happy to help with PRs that refactor the application to make it easier for you to implement this on your end. It's clearly a real possibility, but I think I'd prefer that you maintain it in your own project (with the information and understanding I have currently).

Thank you for your support. Tho this might not be needed by anyone else, I did create a PR with changes suiting my needs:
#264

I guess that if it were to be approved, docs would need to reflect the new setting