IdP Example: Azure Active Directory¶
In addition to numerous other features, Azure AD may also be used as an identity provider (IdP) for single sign-on access to other cloud services, including Skuid. This can be typically be done following this process:
- Create an identity provider connection in Skuid, which generates a service provider entity ID and an assertion consumer service (ACS) URL.
- Create an Azure AD enterprise application, entering the Skuid entity ID in the related field and the ACS URL as the reply URL.
- Obtain the federation metadata document URL from Azure AD.
- Update Skuid’s IdP connection using the federation metadata document URL.
- Update the identity mapping to expect the correct SAML attribute from Azure.
The example in this section makes three assumptions:
- The Azure AD username attribute is used to verify users.
- Azure AD usernames for this organization match Azure AD email addresses, e.g. john.doe@example.onmicrosoft.com.
- Skuid users’ federation IDs are used to verify Azure AD usernames.
If your organization needs are different than the above, see SAML Identity and Azure AD Attributes for more information.
Note
- Since changing settings within your Azure AD instance can have far-reaching effects on your entire enterprise, Skuid strongly recommends proceeding with the assistance of your resident Azure AD admin.
- These instructions apply to the cloud-based version of Azure AD. If using an older instance, such as the desktop interface, you may still be able to follow along, but the specific steps may differ.
Prerequisites¶
SAML basics¶
- This tutorial assumes you’ve familiarized yourself with the basics of single sign-on (SSO) and Skuid.
- This tutorial assumes a basic knowledge of enterprise application setup in Azure. To learn more, see Microsoft documentation.
SAML Identity and Azure AD Attributes¶
Before you create the Azure AD identity provider connection, consider which data to use when verifying end users within Skuid—meaning, which attribute element can Azure AD send back that correlates with a field on a Skuid NLX 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 Skuid user’s field within the Single Sign-On topic.
Warning
Azure AD 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 AD can send that may relate to your Skuid user’s data:
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name
- Azure AD username, usually an Azure AD 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 AD’s attribute elements, see the Azure AD token reference.
Create an IdP connection in Skuid¶
Creating an IdP connection in Skuid generates an entity ID and ACS URL, which you’ll need when configuring your enterprise application in Azure AD.
In your Skuid NLX site:
- Navigate to Settings > Single Sign-on.
- Click Create identity provider or, if some IdP connections already exist, click Create in the Identity Providers section.
- Give the IdP connection a name, like Azure.
- Confirm the name by clicking Create.
- Copy the service provider entity ID and ACS URL values.
Create an enterprise application in Azure AD¶
Within the Azure AD portal:
- Navigate to the Enterprise applications service.
- Click + New application.
- Click + Create your own application.
- Enter a relevant name, like SkuidSSO and create it as a Non-gallery application.
- 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 to Skuid¶
With the application created (and assigned), use Skuid’s SSO values in application single sign-on settings.
- Click Single sign-on in the sidebar.
- Click SAML as the single sign-on method.
- In the Basic SAML Configuration section, click Edit
- In the Identifier (Entity ID) section, click Add identifier.
- Paste Skuid’s service provider entity ID.
- In the Reply URL (Assertion Consumer Service URL) section, click Add reply URL.
- Paste ACS URL.
- Click Save.
Update Skuid’s IdP connection using the federation metadata URL¶
With Azure’s settings complete, locate the federation metadata document URL, which is used to update Skuid’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 Skuid NLX site:
- Navigate back to the IdP connection you created in Settings > Single Sign-on.
- In the Identity provider details section, click Add details.
- Select Import metadata file from specified URL.
- Paste the federation metadata document URL copied earlier into the field.
- Click Import.
Add identity mapping¶
Once SAML metadata is loaded, you must create an identity mapping so Skuid can identify users based on the information sent by Azure.
Note
This mapping example assumes you’re using the …/claims/name Azure AD attribute as a federation ID. If this isn’t the case, update the mapping to match your implementation.
In the Identity mapping section, click Add mapping.
Configure the mapping:
[ SAML attribute ] [ http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name ] matches Skuid user [ Federation ID ]
Indicate whether or not the match is Case-sensitive.
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 AD sends and how Skuid verifies a SAML identity. If there are errors, review the SAML Identity and Azure AD Attributes section to specifically check:
- The Identity Location section of your Azure AD identity provider connection:
- SAML Identity is in must be set to An Attribute element.
- Attribute Name must match an attribute URL from the Azure AD token reference. These URLs begin with
http://schemas.
- The chosen value SAML Identity contains Skuid User’s must match the Azure AD attribute.
If unsure what information Azure AD is sending when users attempt to login, visit Skuid’s Login History:
- Navigate to Settings > Login History.
- Look for any attempts that have the SAML Login Type.
- Click chevron-small-down Login details.
Under the SAML Details section, Skuid displays details of the login attempt listed in JSON format. In particular, verify the attributes
values match a Skuid 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 Skuid site URL:
AADSTS70001: 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 Skuid’s IdP connection. To review, see the Connecting the enterprise application to Skuid section.
AADSTS50011: 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 AD app registration may not match the IdP connection’s ACS URL in Skuid.
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 Skuid section.