implement SAML SSO

Answers (3)

winstonhong

Reputation: 1349

Question 1:

I'm building a SaaS and my idea is to allow my customers to use their own authentication system to login to my app.

what's the best approach to do this? I will have multiple customers and each of them can configure SAML SSO.

Answer:

(1) A unique subdomain is assigned to each customer, for example,

customer1.your-software.com
customer2.your-software.com
customer3.your-software.com

(2) The subdomain of each customer corresponds to a SAML SP with corresponding SAML SP metadata. The entityID and AssertionConsumerService endpoint of SAML SP for each customer should be different.

For exmple, assume that Shibboleth SAML SP is used, entityID of each customer can be

https://customer1.your-software.com/Shibboleth.sso/Metadata
https://customer2.your-software.com/Shibboleth.sso/Metadata
https://customer3.your-software.com/Shibboleth.sso/Metadata

AssertionConsumerService endpoint of each customer can be

https://customer1.your-software.com/Shibboleth.sso/SAML2/POST
https://customer2.your-software.com/Shibboleth.sso/SAML2/POST
https://customer3.your-software.com/Shibboleth.sso/SAML2/POST

(3) Each customer can upload their unique SAML SP metadata to their their own authentication system (i.e., SAML IdP (Identity Provider)).

Cloud-based SAML SP enterprise application Salesforce has implemented the similar solution described above.

Similarly we have implemented a parallel solution for our cloud-based SAML IdP which is part of of Zero-Password Authentication and Authorization System.

Question 2:

I'm also concerned about how to initially load the users. Usually companies provide a list of users emails and I just bulk insert them into the database or the account will not have any users until they start to sign in?

Answer:

Because SAML SP and SAML IdP (i.e., your customer's own authentication system) have established the mutual trust through metadata exchange, SAML SP (equipped with your enterprise software) should trust all the user info federated from SAML IdP (i.e., your customer's own authentication system).

(1) The account will not have any users until they start to sign in.

(2) When a new user initially signs in to your cloud-based enterprise application, after failing to find the user info from the database, your enterprise web application will insert the new user info into the database.

Question 3:

How to manage the scneario when a user is not part of a company anymore? companies provide a list of users to deactivate?

Answer:

(1) When a user is not part of a company anymore, your customer will deactivate the user from their authentication system. Then the user is NOT able to log in to your cloud-based enterprise web application

(I) When a user accesses your cloud-based enterprise web application, the user is redirected to your customer's own authentication system (i.e., SAML IdP).

(II) The deactivated user will NOT be authenticated by your customer's own authentication system.

(III) The deactivated user will NOT be redirected back to your cloud-based enterprise web application with SAML assertion/response which carries the user info. Thus, the deactivated user will fail to log in to your cloud-based enterprise web application.

(2) Your enterprise web application assigns administrative privilege to the IT head of each customer for their own organization subdomain such as customer1.your-software.com.

After logged in to your enterprise web application, the IT head can remove/delete/deactivate any user of their organization such as customer1 from the database of your your enterprise web application.

The official Okta website What is SCIM? provides the following description on SCIM (System for Cross-domain Identity Management).

When changes to identities are made in the IdP, including create, update, and delete, they are automatically synced to the SP according to the SCIM protocol.

Follow-up Question #1:

when the user authenticated with SAML and is redirected to the callback url (my app) what´s would be the ideal flow there?

Answer:

(1) After a user authenticated with SAML IdP, the user is redirected to the AssertionConsumerService URL of your enterprise application which is bound to subdomain of each customer of your enterprise application.

(2) How to build and run Shibboleth SAML IdP and SP using Docker container at GitHub repository provides the instruction on building a SAML-based Authentication/Authorization Provider using Shibboleth SAML IdP and OpenLDAP and a SAML SP web application (which can be regarded as a simplified enterprise application to allow paid users to access protected web resources).

Shibboleth SAML IdP is responsible for identity federation.
OpenLDAP is responsible for identity authentication.

You can use the above GitHub repository to simulate your SAML SP enterprise application with multiple customers and their corresponding SAML IdPs.

(I) Run three (3) SAML SP demo application docker containers (which correspond to three (3) SAML SP enterprise applications subscribed by three (3) customers) on the same physical machine/server (such as Ubuntu server).

(I.A) Each SAML SP demo application runs on different "external" ports of Docker container.

docker run -it --rm -p 2081:80 -p 2441:443 --name="shibboleth-sp-1" example/shibboleth-sp:latest
docker run -it --rm -p 2082:80 -p 2442:443 --name="shibboleth-sp-1" example/shibboleth-sp:latest
docker run -it --rm -p 2083:80 -p 2443:443 --name="shibboleth-sp-1" example/shibboleth-sp:latest

(I.B) Use HAProxy to map different "external" ports of Docker container to different subdomain of your customers, such as

2441 to  https://customer1.your-software.com/
2442 to  https://customer2.your-software.com/
2443 to  https://customer3.your-software.com/

(II) Run three (3) SAML IdP docker containers (which provide SAML authentication for three (3) enterprise applications subscribed by three (3) customers) on another same physical machine/server (such as Ubuntu server).

For demo purpose, you can use two (2) physical machines for SAML IdP and SAML SP with local DNS and port configuration for different domain name, for example,

10.10.40.10 customer1.your-software.com customer2.your-software.com customer3.your-software.com 

10.10.40.11 customer1.saml-idp.com customer2.saml-idp.com customer3.saml-idp.com

(II.A) Each SAML IdP runs on different "external" ports of Docker container.

docker run --rm -it ... -v $(pwd)/ext-conf:/opt/shibboleth-idp-ext-conf --link openldap:openldap -p 8441:8443 --name="shibboleth-idp-1" example/shibboleth-idp:latest $@

docker run --rm -it ... -p 8442:8443 --name="shibboleth-idp-2" example/shibboleth-idp:latest $@

docker run --rm -it ... -p 8443:8443 --name="shibboleth-idp-3" example/shibboleth-idp:latest $@

... means the missing docker parameters to be added (with reference to run.sh)

(II.B) Use HAProxy to map different "external" ports of Docker container to different subdomain of SAML IdP corresponding to your customers' SAML SP application such as

8441 to  https://customer1.saml-idp.com/
8442 to  https://customer2.saml-idp.com/
8443 to  https://customer3.saml-idp.com/

(III) Exchange the SAML metadata between SAML SP (e.g., https://customer1.your-software.com/) and SAML IdP (e.g., https://customer1.saml-idp.com/).

Remarks

You can check the Salesforce SSO and Box SSO website to learn how Salesforce and Box assign different sub-domains to their different customers, thus allowing customers to configure their subdomains as different SAML SPs for customers' own SAML IdPs.

Note that our Zero-Password Authentication and Authorization System is technology partner of Box.

Follow-up Question #2:

should I create a jwt on my app with that information and if that jwt expires I should redirect again to SAML?

Answer:

No. You do NOT need to create a jwt on your enterprise application.

Instead, when SSO session expires, your enterprise application should be redirected to SAML IdP for another authentication.

Follow-up Question #3:

is there a "free" idp I can use to test the implementation are you aware of any?

Answer:

Shibboleth SAML IdP is a "free" idp I can use to test the implementation.

There are two (2) options for leveraging Shibboleth SAML IdP to test the implementation of your SAML SP enterprise application.

(1) Running Standalone Shibboleth SAML IdP

How to build and run Shibboleth SAML IdP and SP using Docker container at GitHub repository allows you to build and run a standalone IdP Simulator at your own testbed. Running a standalone SAML IdP Simulator by yourself allows you to test your SP code and debug your SAML SP log by checking server logs of both IdP and your SP developed by you.

(2) Utilizing the online Shibboleth SAML IdP

TestShib is the online Shibboleth IdP simulator built and run by the Shibboleth community. The website of TestShib demonstrates

"One of the original creators of the TestShib service has built an alternative to TestShib for everyone's benefit. The site is called SAMLTest (offered by Signet)* and you can learn more about them by browsing over to those locations."

Upvotes: 3

Toby

Reputation: 196

I have experience setting up SSO across dozens of apps for an organization with 15-20k users. Here are some tips from experience that may be relevant:

If you have no real need to create accounts, don't. Instead, rely on valid IDP responses as proof that they have been authenticated. If you need authorization, maybe you can rely on the IDP to manage that. AWS, for example, looks for a multi-valued attribute https://aws.amazon.com/SAML/Attributes/Role to determine what role(s) the IDP asserts the user has. If there are no roles, the user is authenticated but can't do anything.
The premise of SSO is that the IDP will no longer authenticate users when they leave, so perhaps you do not need to de-provision users when they leave. If you need to remove stale data in your SaaS (ex. you want to show all organization users but don't want to include those who left), perhaps instead just filter out users who haven't logged into SaaS in some period of time.
If you really do need a method to de-provision accounts (for example, because you allow user-linked API keys which circumvent SSO), you can initially empower organization admins do that manually. I believe Slack uses that model, even for SSO-managed users.
If you want to allow SP-initiated logins (AWS doesn't allow this but gmail does), use a google-like process where a user first inputs only their email address (or an empty password like New Relic). The email will allow you to lookup the organization's IDP details and redirect the user to the organization's own IDP.
The SAML spec is nearly 15 years old, so in addition to SAML, consider supporting OAuth/OIDC. This will allow organizations to rely on GitHub, LinkedIn, etc, for example, as their IDP instead of setting up their own (if you decide you don't need IDP-managed roles).
From go-live, provide support for a few popular IDPs like AD FS, Auth0, Google Apps, etc. to minimize the friction to get your SaaS adopted for corporate use.

Upvotes: 1

bbaassssiiee

Reputation: 6812

Scim is the protocol used to provision users from an identity provider to your database.

Scimgateway is one implementation https://github.com/jelhub/scimgateway

Upvotes: 1

Answers (3)

Related Questions