Single Sign On
Integrate your enterprise login service with Noloco
Last updated
Integrate your enterprise login service with Noloco
Last updated
Single sign on is a feature available for ENTERPRISE
plans on Noloco. Enabling it will disable all other login and sign up features, requiring your users to login with their enterprise credentials. To enable SSO navigate to your login options and configure the integration.
We support SAML 2.0 as a method of SSO in Noloco. To use SAML as a method of login you need to provide us with information about your Identity Provider (IdP) and in turn we will provide you information to set us up as a Service Provider.
To setup a SAML integration click Configure
next to it in the login settings.
You will then see a form open within a modal for you to complete:
This form contains four sections:
Noloco's callback URL for SAML responses
Metadata about your IdP
Attribute mappings for SAML responses
Noloco role settings
This URL is where your IdP should POST
SAML responses to after your users login. You can copy the URL to your clipboard using the button provided and it is likely you will have to whitelist it in your IdP.
We require the following metadata about your IdP to be able to properly configure your SAML integration:
The URL we can contact your IdP at
The public certificate we can use to verify responses from your IdP
The issuer for requests that your IdP expects
The easiest way to configure your SAML integration is by uploading the metadata XML file that your IdP provides to you. You can drag and drop this onto the file dropzone in this form. Alternatively you can expand the configuration section and manually complete it.
We need to know how to build Noloco users from your SAML responses, you can configure this by telling us the attribute names that correspond to each Noloco user field. There are a few places you can look these up. Firstly you might be able to find them in your IdP settings for SAML, e.g. in Auth0 we can see the following in our Settings:
This tells us that the name of the email attribute is http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress
so we would copy this entire value into the Email Address Attribute
input in the configuration form.
Alternatively you might be able to find these in your metadata XML file that you uploaded for the configuration. For the same example we can see the email attribute:
Note that presently we do not automatically detect attribute mappings so even if they are in your metadata XML file you will have to input them yourself.
Finally you can select a default role that all users will be assigned when they first sign into your app with SAML.
You can review your existing SAML integration from the login settings page where we will show you the IdP and any mapped attributes.
You can update the integration by clicking on it and changing the values in the same form that you saw at setup.
To remove the SAML integration click the Remove
button and confirm your choice in the modal that will appear.
When your users try to log into your app, they will be redirected to the /login
page where they will see a redirect out to your IdP.
The /register
, /join
and /forgot
pages will all now also redirect to this login page.
After clicking the sign in button they will be taken to your enterprise login page where they will go through your in-house login flow. After that they will be redirected back to your Noloco app (where if they are new to the app a new user record will be created for them).
Dynamic SSO on Noloco's enterprise plan allows you to configure multiple SSO providers for a single app. This setup is ideal for businesses with different organizations or subsidiaries, each with unique SSO needs. It also supports hybrid authentication, combining SSO for employees with email and password logins for external users like clients.
Advantages of Dynamic Single Sign-on
Multiple SSO Configurations: Useful for companies with multiple subsidiaries or partner organizations.
Hybrid Logins: Enforce SSO for internal users and allow password logins for external users.
Domain-Based Matching: Specify domains to link each SSO configuration to the correct users.
Access the SSO Settings:
Go to your app's Settings and click on Login & Sign-up.
Add Multiple Configurations:
In the SSO section, if you already have SSO setup, you'll see an option to add another configuration. You can add a new SSO setup for each organization or subsidiary.
Specify Domain Matching:
For each configuration, provide a list of domain names that match the organization's email addresses (e.g., @company.com). This ensures that the right users are authenticated with the correct SSO provider.
Hybrid Login Setup:
If you'd like to allow both SSO and password logins, ensure that only internal domains are assigned to your SSO configurations. All other users will fall back to email/password authentication.
Test Your Setup:
Once configured, test each setup by logging in as different users from the specified domains to ensure that SSO is triggered correctly. You can also test fallback to password login for external users.
By default Auth0 is set up to sign the assertions on SAML responses but not sign the entire response. For security reasons we will only accept SAML responses which have a top-level document signature we can verify.
You can configure Auth0 to sign the entire response by going to Applications > [Your Application] > Addons > SAML2 Web App > Settings
and making sure that the settings JSON includes a (uncommented) line with "signResponse": true
. For example:
This error means that the Issuer (entity ID)
configured in your Noloco SAML settings does not match the Identifier (Entity ID)
in your Azure Active Directory settings. You can find more information about resolving this error here.
By default Azure Active Directory is set up to sign the assertions on SAML responses but not sign the entire response. For security reasons we will only accept SAML responses which have a top-level document signature we can verify.
If you don't follow these instructions you will see an "Unauthorized" error when you sign in when using Microsoft Azure Active Directory
Follow the instructions here to configure Azure Active Directory to sign either the response or both the response and the assertions.
Use the following settings for Microsoft Azure Active Directory:
Email Address Attribute
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress
First Name Attribute
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname
Last Name Attribute
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname
The Advanced settings will look like the following:
Entry Point
https://login.microsoftonline.com/********/saml2
Issuer / Entity ID
https://sts.windows.net/********