IdP Example: Azure Active Directory

In addition to numerous other features, Azure Active Directory may also be used as an identity provider (IdP) for single sign-on access to other cloud services, including Nintex Apps. This can be typically be done following this process:

1. Create an identity provider connection in Nintex Apps, which generates a service provider entity ID and an assertion consumer service (ACS) URL.
2. Create an Azure Active Directory enterprise application, entering the Nintex Apps entity ID in the related field and the ACS URL as the reply URL.
3. Obtain the federation metadata document URL from Azure Active Directory.
4. Update Nintex Apps's IdP connection using the federation metadata document URL.
5. Update the identity mapping to expect the correct SAML attribute from Azure.

The example in this section makes three assumptions:

1. The Azure Active Directory username attribute is used to verify users.
2. Azure Active Directory usernames for this organization match Azure Active Directory email addresses, e.g. john.doe@example.onmicrosoft.com .
3. Nintex Apps users' federation IDs are used to verify Azure Active Directory usernames.

If your organization needs are different than the above, see SAML Identity and Azure Active Directory Attributes for more information.

Prerequisites

SAML basics

• This tutorial assumes you've familiarized yourself with the basics of single sign-on (SSO) and Nintex Apps.
• This tutorial assumes a basic knowledge of enterprise application setup in Azure. To learn more, see Microsoft documentation.

SAML Identity and Azure Active Directory Attributes

Before you create the Azure Active Directory identity provider connection, consider which data to use when verifying end users within Nintex Apps —meaning, which attribute element can Azure Active Directory send back that correlates with a field on a Nintex Apps user's data.

The federation ID field is commonly used for this purpose, but you can also use several other fields. For more information about this, see the information about the SAML Assertion contains Nintex Apps user's field within the Single Sign-On topic.

Important:  Azure Active Directory attributes are not currently supported for use in SAML attribute formulas due to their use of : and / characters.

With that in mind, here are some of common attributes that Azure Active Directory can send that may relate to your Nintex Apps user's data:

• http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name
  • Azure Active Directory username, usually an Azure Active Directory email address: e.g. john.doe@example.onmicrosoft.com
• http://schemas.microsoft.com/identity/claims/displayname
  • Full Name, e.g. John Doe
• http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname
  • First Name: e.g. John
• http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname
  • Last Name: e.g. Doe

For more information on Azure Active Directory's attribute elements, see the Azure Active Directory token reference.

Create an IdP connection in Nintex Apps

Creating an IdP connection in Nintex Apps generates an entity ID and ACS URL, which you'll need when configuring your enterprise application in Azure Active Directory.

In your Nintex Apps site:

1. Navigate to Settings > Single Sign-on.
2. Click Create identity provider or, if some IdP connections already exist, click Create in the Identity Providers section.
3. Give the IdP connection a name, like Azure.
4. Confirm the name by clicking Create.
5. Copy the service provider entity ID and ACS URL values.

Create an enterprise application in Azure Active Directory

Within the Azure Active Directory portal:

1. Navigate to the Enterprise applications service.
2. Click + New application.
3. Click + Create your own application.
4. Enter a relevant name, like AppsSSO and create it as a Non-gallery application.
5. Click Create.

Assigning the application to users

Before this application can be used for SSO, it must be assigned to users. This can be done clicking within Users and groups and setting the appropriate assignments. For more information, see Azure documentation.

Connecting the enterprise application

With the application created (and assigned), use Nintex Apps's SSO values in application single sign-on settings.

1. Click Single sign-on in the sidebar.
2. Click SAML as the single sign-on method.
3. In the Basic SAML Configuration section, click Edit
4. In the Identifier (Entity ID) section, click Add identifier.
5. Paste Nintex Apps's service provider entity ID.
6. In the Reply URL (Assertion Consumer Service URL) section, click Add reply URL.
7. Paste ACS URL.
8. Click Save.

Update Nintex Apps's IdP connection using the federation metadata URL

With Azure's settings complete, locate the federation metadata document URL, which is used to update Nintex Apps's IdP connection to properly target Azure.

Within the Azure application's single sign-on settings, copy the App Federation Metadata Url value.

In your Nintex Apps site:

1. Navigate back to the IdP connection you created in Settings > Single Sign-on.
2. In the Identity provider details section, click Add details.
3. Select Import metadata file from specified URL.
4. Paste the federation metadata document URL copied earlier into the field.
5. Click Import.

Add identity mapping

Once SAML metadata is loaded, you must create an identity mapping so Nintex Apps can identify users based on the information sent by Azure.

Note:  This mapping example assumes you're using the .../claims/name Azure Active Directory attribute as a federation ID. If this isn't the case, update the mapping to match your implementation.

1. In the Identity mapping section, click Add mapping.

2. Configure the mapping:

   [ SAML attribute ] [ http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name ] matches Nintex Apps user [ Federation ID ]

3. Indicate whether or not the match is Case-sensitive.

4. Click Save.

Make the IdP available as a login option

With all setup options complete, enable the Available as login option toggle and then click Save to display the newly created IdP connection as a login option to your users.

Troubleshooting

Most issues arise from a mismatch between what Azure Active Directory sends and how Nintex Apps verifies a SAML identity. If there are errors, review the SAML Identity and Azure Active Directory Attributes section to specifically check:

• The Identity Location section of your Azure Active Directory identity provider connection:
  • SAML Identity is in must be set to An Attribute element.
  • Attribute Name must match an attribute URL from the Azure Active Directory token reference. These URLs begin with http://schemas.
  • The chosen value SAML Identity contains Nintex Apps User's must match the Azure Active Directory attribute.

If unsure what information Azure Active Directory is sending when users attempt to login, visit Nintex Apps's Login History:

1. Navigate to Settings > Login History.
2. Look for any attempts that have the SAML Login Type.
3. Click chevron-small-down Login details.

Under the SAML Details section, Nintex Apps displays details of the login attempt listed in JSON format. In particular, verify the attributes values match a Nintex Apps user's details (such as their federation ID).

There are also several specific errors users may see after attempting to login from the Microsoft Online login page. For the example errors below, replace ... with your Nintex Apps site URL:

• AAconnectorS70001: Application with identifier '.../auth/saml/sp/5f6520a2-3ffa-495d-8652-b16a1da95160' was not found in the directory

  The enterprise application's entity Id doesn't match the entity Id of Nintex Apps's IdP connection. To review, see the Connecting the enterprise application section.

• AAconnectorS50011: The reply address '.../auth/saml/sp/5f6520a2-3ffa-495d-8652-b16a1da95160/assert' does not match the reply addresses configured for the application

  The reply URL for your Azure Active Directory app registration may not match the IdP connection's ACS URL in Nintex Apps.

  To verify, check the details for your identity provider connection and ensure that the assertion consumer service (ACS) URL field is set as the enteprise applicaiton's reply URL.

  If you have corrected this, clear the browser's cookies and cache.

  To review, see the Connecting the enterprise application to section.