# Single Sign On Single sign-on is a feature available for `ENTERPRISE` [plans](https://noloco.io/pricing) on Noloco. Enabling it will disable all other login and sign-up features, requiring your users to log in with their enterprise credentials. To enable SSO, navigate to **Settings > Login & Sign Up**, or you can [click here](https://portals.noloco.io/~/_/settings/sign-in). ## SAML We support [SAML 2.0](https://en.wikipedia.org/wiki/SAML_2.0) for SSO in Noloco. To use SAML for login, you need to provide us with information about your Identity Provider (IdP). In turn, we will provide you with information to set us up as a Service Provider. ### Add a SAML integration To set up a SAML integration, click the `Add SSO Provider` button in the **Single Sign-On (SSO)** section.
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
#### Callback URL This URL is where your IdP should `POST` SAML responses after your users log in. You can copy the URL to your clipboard using the provided button, and you will likely need to whitelist it in your IdP. #### IdP metadata We require the following metadata about your IdP to be able to properly configure your SAML integration: 1. The URL we can use to 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 to upload the metadata XML file your IdP provides. You can drag and drop this onto the file dropzone in this form. If you don't have a metadata XML file or prefer to configure manually, select the **Manual Configuration** tab and fill in: * IdP entrypoint (required): The URL we can contact your IdP at, e.g., `sso.mydomain.com/saml` * IdP public signing certificate (required): The public certificate we use to verify responses from your IdP * IdP issuer (Entity ID) (required): The issuer for requests that your IdP expects, e.g., `urn:sso.mydomain.com`
#### Attribute mapping 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: 
{
  ...
  "mappings": {
    "user_id":     "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier",
    "email":       "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress",
    "name":        "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name",
    "given_name":  "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname",
    "family_name": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname",
    "upn":         "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn",
    "groups":      "http://schemas.xmlsoap.org/claims/Group"
  },
  ...
}
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 we do not currently automatically detect attribute mappings, so even if they are in your metadata XML file, you will have to enter them yourself. #### Noloco role Finally, you can select a default role that all users are assigned when they first sign in to your app with SAML. ### Your existing SAML integration 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 you saw during setup. To remove the SAML integration, click the `Remove` button and confirm your choice in the modal that will appear. ### How your users log in 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 Single Sign-on (SSO) 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, such as 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. #### **How to Set Up Dynamic SSO** 1. **Access the SSO Settings**: * Go to your app's **Settings**, then click **Login & Sign-up**. 2. **Add Multiple Configurations**: * In the SSO section, if you already have SSO set up, you'll see an option to add another configuration. You can add a new SSO setup for each organization or subsidiary. 3. **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. 4. **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. 5. **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. ### Troubleshooting SSO #### I'm using Auth0 for my IdP and see *"Unauthorized"* after logging in By default, Auth0 is configured to sign assertions in SAML responses, but not the entire response. For security reasons, we will only accept SAML responses that 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:
Use the following settings for Auth0 * **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` #### I'm using Azure Active Directory for my IdP and see a AADSTS700016 error during the Microsoft login flow This error means that the `Issuer (entity ID)` configured in your Noloco SAML settings does not match the `Identifier (Entity ID)` configuration in your Azure Active Directory settings. You can find more information about resolving this error [here](https://learn.microsoft.com/en-us/troubleshoot/azure/active-directory/error-code-aadsts70001-app-not-found-in-directory). Double check that the `Issuer (entity ID)` configured in your Noloco SAML settings matches the one pictured below in your Azure Active Directory Settings

Double check your Identifier (Entity ID) value if you encouter the AADSTS700016error

#### Using Microsoft Azure Active Directory for SAML By default, Azure Active Directory is configured to sign assertions in SAML responses, but not the entire response. For security reasons, we will only accept SAML responses that have a top-level document signature we can verify. {% hint style="info" %} If you don't follow these instructions, you will see an ***"Unauthorized"*** error when you sign in when using Microsoft Azure Active Directory {% endhint %} Follow the instructions [here](https://learn.microsoft.com/en-us/azure/active-directory/manage-apps/certificate-signing-options#certificate-signing-options) 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** \&#xNAN;**`https://sts.windows.net/********`** --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://guides.noloco.io/settings/login-and-signup/single-sign-on.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.