Allow more flexible configuration (username mapping; endpoint configuration) (Azure Active Directory with Microsoft Graph)

Abdull commented 1 year ago

TL;DR:

nextcloud-social-login versions v5.1.4 and earlier don't work (well?) with Microsoft's popular Microsoft Graph-based Azure Active Directory OAuth2 identity provider.
It would be great if nextcloud-social-login ...
- ... can be configured to not add the {$provider}- prefix to a username.
- ... allows Nextcloud installation administrators to "bring" and use their own provider implementation.

Background (Azure Active Directory with Microsoft Graph)

We have an existing Nextcloud installation with existing LDAP users (using Nextcloud's LDAP user and group backend/LDAP/AD integration app). By default, the LDAP app uses the UUID attribute for the username. In our case (Active Directory), this is the objectGUID, so usernames within our Nextcloud installation are of the form e.g. 12345678-abcd-1234-abcd-1234567890ab.

Organization-wide, we are in the process of migrating LDAP logins to OAuth2 Azure Active Directory with Microsoft Graph, and so I evaluated the current nextcloud-social-login version v5.1.4 for use as our Nextcloud installation's future login provider.

I stumbled upon a few blockers using nextcloud-social-login with Azure Active Directory, all of which I was able to resolve in my fork https://github.com/Abdull/nextcloud-social-login/ . It would be great if nextcloud-social-plugin could incorporate or adapt my improvements.

Improvement 1: Allow username without provider prefix

Currently, nextcloud-social-plugin always prefixes the OAuth2-authenticating username with the provider name. E.g. if I give the "custom OAuth2 provider" the name/title azure, and the signing-in username is someuuid then this will let nextcloud-social-plugin derive the username azure-someuuid.

As mentioned before, by default, our Nextcloud installation already has existing LDAP users with (internal) usernames someuuid, therefore with nextcloud-social-plugin they cannot login into their existing accounts due to the additional azure- prefix. Yes, it is possible to have users manually connect their OAuth/Azure accounts; but this is an additional (and avoidable) user step which most of our Nextcloud users will fail to do before deactivating the "traditional" LDAP login.

That's why I have removed the prefix in my fork; with this change, our users can log in to their existing accounts without having to manually connect their OAuth profile before.

Therefore my suggestion: allow to configure nextcloud-social-login to not add the {$provider}- prefix to a username.

Improvement 2: Allow OAuth2 identity provider-specific implementations

Currently, the provided CustomOAuth2 identity provider class is not flexible/generic enough to be used for all kinds of OAuth2 identity providers, Azure Active Directory Microsoft Graph in particular:

For the profile URL endpoint, CustomOAuth2 assumes a query parameter fields, but Microsoft Graph uses the query parameter $select (yes, with a dollar sign), e.g. https://graph.microsoft.com/v1.0/me?$select=mail,displayName,onPremisesImmutableId .
- That's why I have rewritten the $profileUrl construction accordingly for my use case.
At Microsoft Graph, the user's e-mail address property isn't named email, but mail.
A user's UUID value is different between their "original" (on premise) Active Directory profile and their Azure Active Directory profile. Over at Azure Active Directory, the objectGUID can be found in encoded form within the onPremisesImmutableId property: it is base64-encoded with a quirky byte order.

Therefore my suggestion: Allow Nextcloud administrators to "bring" and configure their own provider implementation. It'd say it would even not be required to provide a web interface for that; this could be done pragmatically in Nextcloud's config.php.

I'm happy to help with incorporating these additions/changes to nextcloud-social-login. But I already thank you very much for what nextcloud-social-plugin accomplishes!

zorn-v commented 1 year ago

... can be configured to not add the {$provider}- prefix to a username.

No, I tired to explain why.

... allows Nextcloud installation administrators to "bring" and use their own provider implementation.

Did you try use azure via OIDC not OAuth ? It more "standardized" and maybe your implementation does not needed with it. For example I suppose that user UUID will be in sub field.

Moreover you can use https://github.com/pulsejet/nextcloud-oidc-login app then and solve "username without prefix"

Abdull commented 1 year ago

@zorn-v, thank you for your answer.

... can be configured to not add the {$provider}- prefix to a username.

No, I tired to explain why.

Okay, searching for "prefix" within this project's issues, I am now aware that there exist previous discussions.

Our Azure AD is self-managed and our "Azure AD-Nextcloud" integration is configured in such way that only accounts from our organization can authenticate ("single tenant"/"home tenant" configuration); hence we are not affected by the security risk which on the other hand exists for "third party public OAuth provider" cases.

As suggested by you throughout the other issues' discussions, I will give the fork https://apps.nextcloud.com/apps/oidc_login a try.

Did you try use azure via OIDC not OAuth ? It more "standardized" and maybe your implementation does not needed with it.

Yes, I tried both, OIDC and OAuth.

For example I suppose that user UUID will be in sub field.

Unfortunately not. As per the Microsoft identity platform ID tokens and the Microsoft identity platform access tokens documentations, sub "is a pairwise identifier - it is unique to a particular application ID", meaning the sub is not only different from any original "on premise" ID (be it objectGUID or sid or whatnot); the sub is also different for each application the same user uses.

Also see https://learn.microsoft.com/en-us/answers/questions/167217/how-is-the-sub-field-in-the-userinfo-openid-endpoi.html .

zorn-v / nextcloud-social-login