SAML login via e-mail address using Azure

Hello everyone,

I’m currently trying to implement Single Sign-on using SAML and Azure.

There are users in the local database who have previously logged in with their user name in the format “company_lastname”.
With SAML, it should no longer be possible to log in with the user name, but only with the e-mail address as this is the unique identifier in Azure.

Is it even possible for Nextcloud, more precisely, for the user_saml app to allow a customer user to log in via SAML with their e-mail address + password instead of username + password? If not, this would mean that the user name would have to be changed to the e-mail address for all customer users, right?

So far I have configured the user_saml app so that the login page redirects to Microsoft correctly. But if a user now tries to log in, depending on the app configuration, either the message “Your account is not provisioned, access to this service is thus not possible” appears or the user cannot be found and is created automatically with the e-mail address as the user name.
Another question would therefore be whether and how automatic creation can be prevented.

Thanks in advance

This is a mapping thing.
Here is the basic logic:

In Entra you define which entra attributes (such as user.principalname) map to which SAML claims.
In Nextcloud you define which SAML claims map to which Nextcloud attributes. It seems that with the SAML app version as of now the only thing that can be configured is the SAML claim that should be used for the uid (the unique user id). With this it is at least possible to avoid duplicate account creation (in other words map to existing local accounts correctly once switching to SAML auth).
You can use whatever claim you want here as long as it matches what you defined in Azure.
Then when logging in with a user’s Microsoft account goes as usual (Microsoft account name and password, for instance), this is unrelated to which claims are sent to Nextcloud in the background.

By the way in azure ad / entra you have the option to do custom claim transformations / calculations so your use case should be possible as long as the constituting elements for the claim are present with your entra user objects.