Microsoft has a feature in their Azure stack called Conditional Access. This feature allows Azure customers to apply policies to either the log-in process to Office 365 or specific apps and tiles within Office 365/Azure. Using this feature, Azure customers can restrict access to applications, such as Outlook, SharePoint, and others, based on several different factors.
Recently, Microsoft added a function to Conditional Access called a 'custom control'. These custom controls allow third-party integration into Conditional Access. This process involved having a registered application by the third-party to be white-listed globally by Microsoft and then providing OpenID Connect (OIDC) endpoints for use by the Azure customer to call out to the third-party's authorization process.
This guide is intended for those end-users and customers who require information on installing and configuring Conditional Access for use with SecureAuth IdP.
Before configuring this, you must have completed the following items:
- Have administrative access of Microsoft Azure
- Have installed a SecureAuth IdP appliance version 9.1+ configured one or more realms for that appliance
- Have Internet Information Services (IIS) for Windows Server installed and configured
- If you are interested in this integration, contact email@example.com , open a support ticket, and mention "Tailoring - Conditional Access"
Configuring SecureAuth IdP
To configure SecureAuth IdP for use with Microsoft Conditional Access, perform the following procedure:
1. Log into your SecureAuth IdP Web Admin Console.
2. Create a new realm to handle the Conditional Access integration. For more on creating a realm, refer to the SecureAuth IdP Realm Guide .
3. Configure the following tabs in the IdP Web Admin Console:
- Overview: the description of the realm and SMTP connections must be defined
- Data: an enterprise directory must be integrated with SecureAuth IdP
- Workflow: the way in which users access the target must be defined
- Multi-Factor Methods: the Multi-Factor Authentication methods that are used to access the target (if any) must be defined
The new realm is significantly customized starting with Step 6.
4. Contact Support per the Prerequisite steps to get the ASPX and code-behind pages then copy them under the root of the newly-defined realm.
A custom pre-authentication page is used to retrieve the user ID from Microsoft for this request. Microsoft sends a HTTP POST with the OIDC parameters and an additional parameter called id_token_hint. This parameter is a JWT a number of claims, including the unique id for the user and their UPN. We need to grab that information and validate the JWT.
5. Using IIS Manager, create an inbound rule for Conditional Access in this new realm by following this procedure:
- Start IIS Manager (Start | Run then type inetmgr and hit Enter).
- In IIS, select the Default Web Site.
- Under Features View, click URL Rewrite.
- At right hand side, under the Actions pane, click on Import Rules.
- Set an inbound rewrite rule under the realm folder (for example, SecureAuth3) as shown in 1.
FIGURE 1. Edit Inbound Rule 1
The URL rewrite rule is used to capture requests and place them on the custom page in order to decode the JWT that Microsoft sends over VIA POST as shown in
FIGURE 2. Edit Inbound Rule 2
For more on the URL rewrite rule, refer to this page .
6. Return to the newly-defined realm in IdP Web Admin Console and click the Data tab.
7. Create a connection based on the data store type (such as Active Directory or SQL Server) in this manner:
a. Scroll down to the 'Set Profile Fields' section and make the following designations:
- Aux ID 1 – userPrincipalName
- Aux ID 2 – otherLoginWorkstations
- Aux ID 5 – otherIpPhone and make it writable. (This field is set from custom pre- authentication page – MSConditionalAccess.aspx.vb)
- Go to the Web.Config file for this specific realm and add this line to modify the AuxID 5 definition:
<add key="MSConditionalAccess-ProfileField" value="AuxID5" />
For more on editing the Web.Config file, refer to this link .
FIGURE 3. Set Profile Fields Section
b. Scroll down to the 'Global Aux Fields' section and designate Global Aux ID 1 as Validated.
FIGURE 4. Global Aux Fields Section
8. Click to select the Workflow tab and perform the following tasks:
a. In the 'Login Screen Options' section, assign the following values to the designated fields.
- Default Workflow – Username | Second Factor
- Public/Private Mode – Public Mode Only
FIGURE 5. Login Screen Options
b. In the 'Customer Identity Consumer' section, perform the following task:
- Receive Token – Token
- Leave other fields as default
FIGURE 6. Custom Identity Consumer
9. Click the Multi-Factor Configuration tab to bring up the Multi-Factor Configuration page and supply the following values.
a. Scroll to the 'Phone Settings' section and supply the following values to the designated fields:
- Phone Field 1 – select One-Time Passcode via Phone Call and SMS
- Phone Field 2 – select One-Time Passcode via Phone Call and SMS
FIGURE 7. Phone Settings Section
b. Scroll down to the 'Email Settings' section and supply the following value to the designated field:
- Email Field 1 – select One-Time Passcode via HTML Email
FIGURE 8. Email Settings Section
10. Click the Post Authentication tab then supply the following values to the designated fields:
a. Select OpenID Connect/OAuth2 from the 'Authenticated User Redirect' drop-down field as shown in9.
b. In the 'User ID Mapping' section, supply the following values:
- User ID Mapping – select Authenticated User ID. The user can choose to map other parameters, if needed.
Name ID Format – select urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified
- Encode to Base64 – select False
FIGURE 9. User ID Mapping Section
c. Scroll down to the 'OpenID Connect/OAuth 2.0 – Settings' section and provide the following values:
- Enable – True
- Issuer – Should be the FQDN/Hostname of the IdP appliance. This must be publicly facing and have a valid SSL certificate.
- Signing Algorithm – Can be either RSA SHA256 (RS256) or HMAC SHA256 (HS256)
- Signing Cert – Can use any certificate that is a private key readable by SecureAuth IdP. Do not use wild cards in a certificate.
- Auto Accept User Consent – True. This provides a cleaner user experience.
- Enable User Consent Storage – True. This provides a cleaner user experience and enables check session endpoints.
- Consent Storage Attribute – The AUX ID 2 that was mapped to a string attribute (for example, otherLoginWorkstations)
Leave the following default: 'Authorization Code Lifetime', 'Access Token Lifetime', 'Refresh Token Lifetime'.
Refer to for an example.
FIGURE 10. OIDC Settings
d. Scroll down to the 'OpenID Connect/OAuth 2.0 – Scopes' section and provide the following value:
- Check the 'discoverable' box at the openid scope as shown in 11.
FIGURE 11. OIDC - Scopes Settings
e. Scroll down to the 'OpenID Connect/OAuth 2.0 – Clients' section, click the Add Client button then supply the following values:
- Name – enter ConditionalAccess or another appropriate name
- Client ID – supply the appropriate client ID for this client
- Enabled/Disabled – check this box
FIGURE 12. OIDC - Clients Settings
f. Scroll down to the 'OpenID Connect/OAuth 2.0 - Client Details' section and provide the following values in the designated fields:
- Enabled – True
- Name – Set to an appropriate name such as ConditionalAccess
- JSON Web Encryption – Disabled
- JSON Web Key URI – Blank
FIGURE 13. OIDC - Client Details
g. Scroll down to the 'Allowed Flows' section and provide the following values in the designated fields:
- Authorization Code – True
- Implicit – True
- Hybrid – False
- Client Credentials – False
- Resource Owner – False
- Refresh Token – True
- Introspection – True
- Revocation – True
FIGURE 14. Allowed Flows Section
h. Scroll down to the 'OpenID Connect/OAuth 2.0 - Client Redirect URIs' section and provide the following value:
- Client Redirect URI – OAuth2ClaimsProvider
FIGURE 15. OIDC - Client Redirect URIs Section
i. Scroll down to the 'OpenID Connect/OAuth 2.0 – Claims' section and supply this value:
- Sub – set to the AUX ID field assigned the userPrincipalName value (as shown in Step 7a) and mark it as discoverable.
FIGURE 16. OIDC - Claims Section
j. Scroll down to the 'OpenID Connect/OAuth 2.0 – Custom Claims' section and assign the following values:
- Claim – SecureAuthMFA
- Profile Property – Global Aux ID 1
- Discoverable – Checked
An example is shown in
FIGURE 17. OIDC - Custom Claims Section
11. Save all changes made to this configuration and exit.
Configuring Microsoft Custom Control
To create a new custom control for Microsoft Conditional Access, perform the following steps.
- Log into Microsoft Azure.
- Click Azure Active Directory from left vertical menu.
- Click Security | Conditional Access.
- Click Manage | Custom Control.
- Click New custom control.
- Enter the JSON for customized controls as shown in .
FIGURE 18. Conditional Access - Custom Controls
7. Supply the following values for JSON fields as shown in
- App ID – enter the data applications that MSFT has referenced.
- ClientID – retrieve from the designated realm under the 'OpenID Connect/OAuth 2.0 – Clients' section (refer to ).
FIGURE 19. JSON Field Assignments
Creating a New Policy
To create a new policy for this configuration in Conditional Access, follow these steps:
- Log into Microsoft Azure.
- Click on Azure Active Directory from left vertical menu.
- Click Security | Conditional Access | Policies | New Policy.
FIGURE 20. New Policy Button
4. Specify the users, apps, and controls as required.
FIGURE 21. Policy Assignments
5. When you have finished, click Save.