Multi Tenant SAML Integration in application

What is SAML 2.0?

SAML is an IT standard for exchanging authentication and authorization data (SAML assertion based on XML) between heterogeneous security domains.

There are usually two participating entities:

Identity Provider: abbreviated IdP is a system entity that creates, maintains, and manages identity information for principals (users) and also provides authentication services to relying on applications within a federation or distributed network. Usually, these systems are part of the IAM (Identity Access Management) world with WAM (Web Access Management) modules

Service Provider: Application that provides a service protected by SAML2 security

How to Setup SAML SSO for your application

With spring boot, we can configure relying parties in the application.properties file and when the container ups, it will register all the parties for authentication. But, if you want to give the control to the user to manage this IDP data then relying on the properties file will not be a scalable option.

Here, let’s say the user wants to have the below requirements with SAML

• On the fly provisioning the new IDPs
• Enable Disable SAML SSO login
• Enable auto-provisioning of user

With the custom requirements, it is hard to achieve with spring boot provided IDP provider library. So, we have to go with a custom SAML login flow. Let’s try to understand it in detail.

1. When a user clicks on the sign-in with SAML, the popup appears on the screen, and the user can provide the Okta credentials to log in to your system.
2. The user will setup up a SAML login for his account. After that, the user from his organization will be able to log in through SAML to your application.
3. Along with that, the customer will also provide the domain for which these IDPs will be used to sign in.
4. Sign in through SAML
5. When a user wants to sign in, we will ask the user to enter their email address. Based on the email address backend will get the domain name from the email and from the domain, the backend can fetch the IDP Metadata.
6. From IDP metadata it will fetch the Single Sign-On Service Endpoint and it will generate the SAML request.
7. Destination: SSO Target URL
8. AssertionConsumerServiceURL: Application SSO callback url
9. After that, the user will be providing the okta credentials and after successful authentication, the call will be redirected to the AssertionConsumerServiceURL
10. Consuming Saml Response.

Here, we will have to write a separate REST endpoint to consume the SAML response.

The endpoint we have, we will accept the SAML response and validate it. The validation happens on the signature and certificate. If everything is valid then we have to extract the Subject from the SAML response and then we can get the email id of the user requesting the pager. We can create the user if the user does not exist in the system or we can redirect him to the home page.

The SAML response was posted by the IDP provider. Contains the certificate info and the Subject along with other information.