Single Sign On
Integrate your enterprise login service with Noloco
Single sign on is a feature available for
ENTERPRISEplans 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
Configurenext 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:
- 1.Noloco's callback URL for SAML responses
- 2.Metadata about your IdP
- 3.Attribute mappings for SAML responses
- 4.Noloco role settings
This URL is where your IdP should
POSTSAML 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:
- 1.The URL we can contact your IdP at
- 2.The public certificate we can use to verify responses from your IdP
- 3.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/emailaddressso we would copy this entire value into the
Email Address Attributeinput 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
Removebutton 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
/loginpage where they will see a redirect out to your IdP.
/forgotpages 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).
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 > Settingsand 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.