First of all great job with Nextcloud, keep up the good work !
I am trying to setup federation for my users using SAML for my Nexcloud Server.
I am running Nextcloud 10.0.1 on FreeNas 9.10.1 (FreeBSD).
I have enable the saml app within Nextcloud and have configured my SP; I am using F5 BIG-IP APM as SAML IdP.
I believe my SAML configuration to be ok, AuthnRequests looks good, and the assertion sent back to NextCloud SAML ACS looks correct as well.
When the SAML assertion is posted, a RelayState parameter is used in the same request with this value: https ://domain.com/apps/user_saml_saml/login (this is inherited from the initial RelayState provided by the SP (Nextcloud) during the AuthNRequest. However, I am receiving a redirection by Nextcloud to https ://domain.com/ afterwards (not the RelayState URL). Then follows another redirect to https://domain.com/login and then finally another redirect to https ://domain.com/apps/user_saml/saml/login?requesttoken=… and the saml auth process loops like this indefinitely.
The SAML assertion’s timestamp are correct, the response and assertions are signed by the IdP’s certificate as expected by Nexcloud’s configuration.
I am using for the subject the unspecified NameID format, the PasswordProtectedTransport for the AuthnContextClass and a “uid” attribute for the authenticated username.
Any idea what I am doing wrong ?
Do I need to create the user beforehand or would they be created on the fly ?
I managed to fix it by restoring a snapshot of the initial configuration and redid it from scratch, not 100% sure went wrong here.
If I may, here are some things I wish were present while configuring SAML on Nextcloud.
When I did my initial configuration I used the IP address of my Nextcloud, therefore the SP’s metadata were not using the target SP domain name, so we should start the SAML config after adding a trusted domain name and managing nextcloud using it (that is not super obvious at first). Maybe you could add a field for the SP setting where the SP entity ID is configurable ?
The first field under general is where the attribute is expected to match the username.
When a value is in that field, you no longer know what that field is for (the only explanation is there when the field is cleared).
I normally use the SAML subject for user identification but here only an attribute works; couldn’t you allow the subject to map the username and only use attributes for group, group admin, quota ?
Do you intend to allow IdP metadata import to simplify IdP configuration ?
One other thing, I am using Nextcloud behind a reverse proxy that does the SSL offloading. In this scenario, although the client is using HTTPS only, the AuthnRequest generated by the server contains a Issuer with http only (because it’s hit using plain http on the serverside I suppose). It’d be great to support this scenario and have the SP aware it’s being SSL offloaded. Again this should be achieveable if you could hard set the SP settings.