Self-hosted SSO connection

[Teeldt]

Hi everyone!

I am running shelf as a self-hosted docker container, with a local Supabase setup. Most parts of the setup is going well, and in Supabase I have setup for SSO (Google) so that I can authenticate users with Supabase, but it fails my Shelf logins. When entering my site, choosing to login with SSO and choosing my configured email domain, I am correctly forwarded to Google login. Then I get 403 Error: app_not_configured_for_user.

I have followed the instructions on these pages, with some necessary modifications along the way to accommodate my setup.

1. https://github.com/Shelf-nu/shelf.nu/blob/main/docs/sso/README.md
2. https://github.com/Shelf-nu/shelf.nu/blob/main/docs/sso/providers/google-workspace.md
3. https://supabase.com/docs/guides/auth/enterprise-sso/auth-sso-saml
4. https://calvincchan.com/blog/self-hosted-supabase-enable-sso
5. https://calvincchan.com/blog/240228_self_hosted_supabase_with_saml_attribute_mapping

I had to manually add database entries in Supabase to follow step 9 in instruction 2, where the group ids are supposed to be linked to access groups in the Shelf GUI, those settings are unavailable in the interface. I'm not entirely sure they're entered correctly, but it does look reasonable. I have a row in the public."SsoDetails" table with a made up id and otherwise settings according to the image. In public."Organizations" I have manually set enable_SSO to true, and linked the SsoDetailsId to my entry in that table.

When testing the SAML login from the Google interface, I am correctly referred back to the ACS URL into my Supabase database. Then I get successful login in the SAML log. But when logging in through the shelf application, I instead get error "failed to login because of the following error: Application not configured", which to me indicates that something is off either within Shelf or in its connection with Supabase. I don't get any error messages in neither shelf container, or any of the supabase containers, but I can see that proper requests are made.

Do any of you have any ideas for how I may be able to solve this?

[DonKoko]

Hey @Teeldt,

that seems indeed like an issue in config. We currently have multiple organizations using SSO via Google Workspaces and it has no issues. Keep in mind we use hosted supabase, and I know there are some limitations with SSO when self-hosting supabase but I am not aware of the details as I never used it.

I had to manually add database entries in Supabase to follow step 9 in instruction 2, where the group ids are supposed to be linked to access groups in the Shelf GUI, those settings are unavailable in the interface. I'm not entirely sure they're entered correctly, but it does look reasonable. I have a row in the public."SsoDetails" table with a made up id and otherwise settings according to the image. In public."Organizations" I have manually set enable_SSO to true, and linked the SsoDetailsId to my entry in that table.

You should create a super-admin user in order to be able to do this properly. I suspect doing it manually like you did it could be causing the issue. To enabled super-admin rights for a user, you need to manually add an entry in _RoleToUser. You should do that and use the UI to enable SSO for your user.

Also I am not sure how you did the IDP connection. You should follow the guide from supabase cli and make sure to use the attribute mapping file you can find in ~/sso/attributes.json
Last but not least, when attempting the login via sso, open the network tab in your browser. You should be able to see the errors returned by the oauth there.

Good luck, hope that helps.

[Teeldt]

Thank you for your reply.

In Roles I have Admin and User to choose from. In _RoleToUser I added the entry linking my user to admin (tried first having both roles and removing the User role). With my manual db entry in SsoDetails present, I was now able to see the GUI settings for the workspace, however when I removed it to be able to add it through the GUI I couldn't see it anymore. When adding it back manually by inventing an id (as before), I see the options again. So at least my access is somehow elevated now.

I have done attribute mapping for Supabase, using the ~/sso/attributes.json. That should work as expected. I noticed that I did a mistake in my supabase setup where I set the parameter SITE_URL to my supabase instance instead of my shelf instance. This did not make me get further though.

When logging in through SSO and reading the network file, I get error here:
Request URL:
https://accounts.google.com/o/saml2/idp?idpid=[REDACTED]&SAMLRequest=[REDACTED]&RelayState=[REDACTED]&SigAlg=http%3A%2F%2Fwww.w3.org%2F2000%2F09%2Fxmldsig%23rsa-sha1&Signature=[REDACTED]
Request Method:
GET
Status Code:
403 Forbidden
Remote Address:
209.85.233.84:443 (WHOIS returns Google as IP owner)
Referrer Policy:
strict-origin-when-cross-origin

When using the test SAML option in Google I instead end up with this error (and sent to the start site of shelf)
Request URL:
https://[shelf URL]/?error=invalid_request&error_code=validation_failed&error_description=SAML+Assertion+is+not+valid
Request Method:
GET
Status Code:
302 Found
Remote Address:
86.107.103.80:443
Referrer Policy:
strict-origin-when-cross-origin

Do you have any further recommendations for how to move forward?

[DonKoko]

The url (https://[shelf URL]/?error=invalid_request&error_code=validation_failed&error_description=SAML+Assertion+is+not+valid) contains the error: SAML Assertion is not valid. This is either a supabase or google workspaces issue. Seems like the connection is not created properly. You have to make sure all the URLs are setup correctly in the connection as well as on the google workspaces side.
Here is also something I found online:

The error message SAML Assertion is not valid means that Supabase has received a SAML assertion from Google Workspace but cannot validate it. In SAML-based SSO, the assertion is an XML document that contains information about the user (e.g., their identity) and is signed to ensure its authenticity. If Supabase deems it "not valid," the assertion either doesn’t meet the expected format, contains incorrect data, or fails a security check like signature verification. The additional parameters error=invalid_request and error_code=validation_failed reinforce that the issue lies in the SAML exchange, specifically with the assertion’s validity.

[Teeldt]

Thank you for your support! If someone in the future finds this thread, then I can just add some of the more non-obvious workarounds I needed to get this up and running:

I had to rewrite all /auth/v1/* paths by removing it for all URIs to my supabase instance. In caddy it's something like this:

supabase.example.com {
	rewrite /auth/v1/* /{path}
	reverse_proxy localhost:8000
}

When no SsoDetails entry existed, the settings where not showing at all. By creating an entry in the db directly, and setting for the Organization that SsoEnabled is true and SsoDetailsId to my entry, they actually show up as in example. I needed your recommendation of adding an entry in _RoleToUser to see this in the GUI.

For some reason I couldn't get "metadata_file" to work for supabase self-hosted within docker. Google does not provide a metadata_url. I ended up locally hosting it like

google_idp.internal.example.com {
    root * /srv
    file_server
}

where internal.example.com is reachable within my network and for supabase. And add the path where my metadata.xml file was stored to caddy as internal /srv

    volumes:
      - ./path_to/shelf-metadata.xml:/srv/metadata.xml

Then it was possible to add SAML identity provider to Supabase.