SSO/SAML Support for Supabase Local

[tedsmitt]

The addition of SAML/SSO support in Supabase Auth was a very welcome addition! Great work!

I'm currently working on building an application that will make heavy use of this. Unfortunately, I'm only able to test this using my hosted plan. Are there any plans to add SAML/SSO support to Supabase local?

I had a quick play around by adding the GOTRUE_SAML_ENABLED to the gotrue container that supabase-cli creates, but Kong didn't seem to take me anywhere when navigating to the relevant /sso route. I'm probably missing something, if someone can point me in the right direction I'd be willing to take a shot at submitting a PR?

Cheers!
Ed

[colegottdank]

Hey @tedsmitt, any update on this? Were you able to progress any further? Thanks

[colegottdank]

I was able to get the http://localhost:8000/auth/v1/sso/saml/metadata?download=true url to work and return the xml.

I set GOTRUE_SAML_ENABLED:true and set the GOTRUE_SAML_PRIVATE_KEY

[tedsmitt]

Nice one @colegottdank! I'll try this asap!

[colegottdank]

@tedsmitt found out even more. The sso endpoints require apikey, this won't work for the acs and metadata endpoints. To fix this, you have to update the kong.yml to include them in the open auth routes:

services:

Open Auth routes

• name: auth-v1-open-sso-acs
  url: "http://auth:9999/sso/saml/acs"
  routes:
  • name: auth-v1-open-sso-acs
    strip_path: true
    paths:
    • /auth/v1/sso/saml/acs
      plugins:
  • name: cors
• name: auth-v1-open-sso-metadata
  url: "http://auth:9999/sso/saml/metadata"
  routes:
  • name: auth-v1-open-sso-metadata
    strip_path: true
    paths:
    • /auth/v1/sso/saml/metadata
      plugins:
  • name: cors
• name: auth-v1-open
  url: http://auth:9999/verify
  routes:
  • name: auth-v1-open
    strip_path: true
    paths:
    • /auth/v1/verify
      plugins:
  • name: cors
• name: auth-v1-open-callback
  url: http://auth:9999/callback
  routes:
  • name: auth-v1-open-callback
    strip_path: true
    paths:
    • /auth/v1/callback
      plugins:
  • name: cors
• name: auth-v1-open-authorize
  url: http://auth:9999/authorize
  routes:
  • name: auth-v1-open-authorize
    strip_path: true
    paths:
    • /auth/v1/authorize
      plugins:
  • name: cors

Lastly, once you want to add a provider, you will need to manually hit the admin endpoints:
https://github.com/supabase/gotrue/blob/master/openapi.yaml#L1434-L1600

I plan on making a write up about this soon.

[calvincchan]

Hello folks, thanks to the information above, I was able to set up SSO on my self-hosted Supabase suite. However it still took me a while to figure out all the steps. For future reference, I have documented the whole process here: https://calvincchan.com/blog/self-hosted-supabase-enable-sso

Hope it helps those people who want to enable custom SAML SSO for your own Supabase deployment.

[prewittridge-jonathan]

@calvincchan great work! Have you had any success with mapping the user name information (first name, last name) from Auth0 into Supabase? I was looking into attribute_mapping but have had no luck so far.

[calvincchan]

I couldn't figure out the attribute mapping from ID Provider to Supabase, and due to time constraint I didn't have time to dug deeper into it. If one can figure it out and share it here, it will be much appreciated.

[prewittridge-jonathan]

I couldn't figure out the attribute mapping from ID Provider to Supabase, and due to time constraint I didn't have time to dug deeper into it. If one can figure it out and share it here, it will be much appreciated.

I was able to get the name to map in properly. You can add additional data to the attribute_mapping with the sso provider as shown below:

"attribute_mapping": { "keys": { "email": { "name": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress" }, "name": { "name": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name" }, "nickname": { "name": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name" }, "given_name": { "name": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname" }, "family_name": { "name": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname" }, "picture": { "name": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/picture" }, "user_id": { "name": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier" } } }

This would go in the POST call curl -X POST http://localhost:8000/auth/v1/admin/sso/providers \ that you provided in your blog. Also, you could update the existing provider attribute_mapping via the SQL editor in supabase.

Hope this helps!

[calvincchan]

Thank you @prewittridge-jonathan for sharing. I will update my blog for the record.

[calvincchan]

Hello, I just updated my blog with a new guide to attribute mapping: https://calvincchan.com/blog/240228_self_hosted_supabase_with_saml_attribute_mapping
Thanks to @prewittridge-jonathan again for the solution.

[lecramr]

Hello, I just updated my blog with a new guide to attribute mapping: https://calvincchan.com/blog/240228_self_hosted_supabase_with_saml_attribute_mapping Thanks to @prewittridge-jonathan again for the solution.

Hey great blogpost! Can this also be used for local development? Is there any other known way to enable SAML on the local instance, to develop against it?
Thanks in advance!

[calvincchan]

Hello @lecramr

By "Enable SAML on the local instance" I assume you mean running an Identity Provider locally, rather than using web services like auth0.com.

I found a docker image that you can quickly use to spin up a local IdP: https://github.com/simplesamlphp/docker-simplesamlphp it should work with Supabase as long as you update the connection config accordingly.

Hope it helps!
Calvin

[lecramr]

Hey Calvin,
no sorry for the unclear message. I meant adding (& enabling) SAML login on the local supabase dev environment. So that I would be able to test company onboarding via SAML locally instead currently on my live instance :/. As a SAML Faker I currently use https://mocksaml.com/ which works really great with supabase. But becuase SAML Identity Provider is disabled in the local environment only in live.

Thanks anyway!