Microsoft Entra ID (Azure AD)
Step by step guide on how to configure Azure AD SSO
Last updated
Step by step guide on how to configure Azure AD SSO
Last updated
Copyright © 2023 configure8, Inc. All rights reserved.
Summary - Integrating with Okta SSO
Go to Home -> Enterprise applications -> Create your own application.
After the application is created, enter it go to the Single Sign-on menu, and select SAML:
In the Azure Single Sign-On configuration, edit step 1 and add:
Identifier as "https://app.configure8.io".
Get your "Organization ID" value from the configure8 application in Settings -> Organization -> Organization ID. It should be a hash string, for instance: "7c4b66c9-22db-r2d2-8cea-126e781a5d42" .
Set the Reply URL as "https://app.configure8.io/api/v1/auth/saml/7c4b66c9-22db-r2d2-8cea-126e781a5d42/callback", replacing with your Org ID.
Index as "1". We will verify this in the end after generating metadata on the configure8 interface.
Save.
Copy the Login URL from step 4:
Go to the configure8 SSO menu (Settings->Identity Management->SSO->Setup SSO) and paste it on the Login URL.
Download the Certificate (Base64) in step3:
Open the certificate in a text editor. Be sure to copy the whole content, including the BEGIN and END certificate lines, like this:
Some text editors can change the formatting of a file while opening it. We have seen problems using Windows Notepad to copy this information. In that case, we recommend using VS Code or another programming text editor.
Go to the configure8 SSO menu (Settings->Identity Management->SSO->Setup SSO) and paste it on the Signing Certificate:
When configuring Single Sign-On (SSO) for our application, you can provide a JSON object with various settings to override the default SSO configuration values. Below is a documentation of each available setting in the JSON configuration:
acceptedClockSkewMs: This setting defines the number of clock skew milliseconds acceptable when processing assertions. The default value is 0, which means no clock skew is allowed.
authnContextClassRef: This setting specifies the AuthnContextClassRef to be used when requesting authentication. By default, it uses urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport, which indicates a password-protected transport.
disableRequestedAuthnContext: If set to true, the application does not request a specific authentication context. This is beneficial when authenticating against Active Directory Federation Services (AD FS) servers, as it may prevent potential issues related to the requested authentication context. By default, this setting is false.
forceAuthn: This boolean value dictates whether to force authentication each time an authentication request is made, even if the user has a valid session. The default setting is true.
identifierFormat: This format identifies the entity's principal (usually the user). It defaults to urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress, indicating an email address format is expected.
raComparison: This setting determines how the RequesterId will be compared, with the default being "exact", which requires an exact match.
signatureAlgorithm: This setting defines the algorithm used for signing. The default is sha1.
skipRequestCompression: When set to true, this setting disables compression of the SAML request to the identity provider (IdP). By default, this is set to false, enabling compression.
xmlSignatureTransforms: This array defines the transformations applied to the XML before signing. The default includes the transformations for enveloped signatures and canonical XML (http://www.w3.org/2000/09/xmldsig#enveloped-signature and http://www.w3.org/2001/10/xml-exc-c14n#).
Please ensure the JSON object is well-formed and has proper key-value pairs, as indicated by the provided example settings. Incorrectly formatted JSON can lead to configuration errors.
After saving, you will be provided with a Sign-on URL for your users to log in:
You are also provided with the metadata when clicking in the Generate Metadata.
Double-check the entityID, Location, and index. They should be the same as those you provided in Azure Step 1—Identifier, Reply URL, and Index. In case values are different, go into Azure configuration Section 1 and update them there.
The other highlighted field, emailAddress, shows that the "Unique user identifier" field has to be the email, as we will see in the next section.
It's all done in the general setup. The next step is to set up User Attributes.
Edit the section 2 - Attributes & Claims:
As shown in the metadata we saw in the above section, the Unique User Identifier (Name ID) should be the Email Address:
For configure8 SSO, the following Additional claims values must be created:
Make sure you don't have a namespace defined for the email, FirstName, and LastName new claims, like this:
Other attributes mapping may be enabled by default in your organization. That won't affect configure8.
Each organization may have different fields for FirstName, LastName, and Email. The mapping should be changed to reflect your organization's settings in Azure AD.
If you encounter the error message: "AADSTS75011: Authentication method ‘X509, MultiFactor’ by which the user authenticated with the service doesn’t match the requested authentication method ‘Password, ProtectedTransport’.
This typically happens when the authentication method doesn't align with what's expected. Here's a plain-talk fix:
Head on over to Configure8 Identity Management. Look for the edit icon matching what you saw in the earlier image we discussed. Once you're in the edit mode, navigate to the JSON settings section. You're going to change disableRequestedAuthnContext from false to true.
By toggling this to true, you're telling the system, "Hey, let's not be so picky about the authentication context," which is a handy trick when dealing with AD FS quirks. It's like smoothing out a handshake between your app and the user's ID provider.
Remember to save your changes, and you should be good to go!
