Microsoft Entra ID (Azure AD)

Step by step guide on how to configure Azure AD SSO

Summary - Integrating with Okta SSO

1. Create application in Azure

2. Set up SSO in Azure and configure8

3. Set up user attributes

Create application in Azure

Go to Home -> Enterprise applications -> Create your own application.

Set up SSO in Azure and configure8

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:

1. Identifier as "https://app.configure8.io".

2. 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.

3. Index as "1". We will verify this in the end after generating metadata on the configure8 interface.

4. 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:

-----BEGIN CERTIFICATE-----
MIIC8DCCAdigAwIBAgIQViYFMG3W1rpxyz123kqhkiG9w0BAQsFADA0MTIwMAYDVQQD
EylNaWNyb3NvZnQgQXp1cmUgRmVkZXJhdGVkIFNTTyBDZXJ0aWZpY2F0ZTAeFw0yMzA4MDQxNzU1
MDJaFw0yNjA4MDQxNzU0NTFaMDQxMjAwBgNVBAMTKU1pY3Jvc29mdCBBenVyZSBGZWRlcmF0ZWQg
U1NPIENlcnRpZmljYXRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAnJ/qJniNA+/3
QlPcVSENEeWOXwP+w/wNEx8kMWG5WviMTvB2REMrT+AKUabcdef421M4ngI2lBuHCsoucoR6y
7pMPJjxk4y+hkV66cE3wQKE827g58mByUpeRgHPEsMnoAmR/1KKKZIhdHpXWK0Fo5sHdPaLzyxLC
zjS/XfcOmUKxnFScZp4PSSfnkWyGXZireWTxo51dIV+jN6OB9cNbJQ753lqv+UaT5C9b9NDJ/cb7
W5zpGCwrcnDHtYj/vdECLCL8FPhgUYYYYYYYDEx7FN4esREEZonzTQoCo9g/OhMQNNvqsbT
NQ+2cB5PgnR2dz5ndXYu8VpWJQIXXXXXXXSIb3DQEBCwUAA4IBAQB5oN/Efsj6ifhHD463
NfREOPwayktLj/hUPhsUf8V5QS5NZao3GyB3+OM9JbwopUl2YhpNUpnv6F7zb/oyUu+Ir7wp4+cM
eP/uc0zABCABCTZ/Qf7Q5Cz4BtjYyuLrT9VPtqhrRkCgCIx7r9tLxrFKzj5Njrwcv6SELK
eZRPqrNeyLFVCcY5mUvLrV1te3pYM1svxDypT/9HtDqRwp5amWfDINsps551nGh7c9tuNqR/0n21
00qP+XrzVMbVLAPSltiLc0EWtMREPcOBORM+iAsTqurTmMpyxOAhSRqRQpUOcavF5esKeQUpUbqX
k6055llA5qgQ1m1npr67
-----END CERTIFICATE-----

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:

SSO Configuration Settings

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:

1. 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.

2. 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.

3. 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.

4. 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.

5. 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.

6. raComparison: This setting determines how the RequesterId will be compared, with the default being "exact", which requires an exact match.

7. signatureAlgorithm: This setting defines the algorithm used for signing. The default is sha1.

8. 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.

9. 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.

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.

Known Issues & Solutions

Issue: AADSTS75011 Authentication Method Mismatch

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:

How to Resolve It

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!