You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 14 Next »


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.

Intended Audience

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 and 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, 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:

    1. Start IIS Manager (Start | Run then type inetmgr and hit Enter).
    2. In IIS, select the Default Web Site.
    3. Under Features View, click URLRewrite.
    4. At right hand side, under the Actions pane, click on ImportRules.
    5. Set an inbound rewrite rule under the realm folder (for example, SecureAuth3) as shown in Figure 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.

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 | SecondFactor
      • Public/Private Mode – Public ModeOnly

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-TimePasscodeviaPhoneCallandSMS
      • 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 HTMLEmail

FIGURE 8. Email Settings Section

10. Click the Post Authentication tab then supply the following values to the designated fields:

a. Select OpenIDConnect/OAuth2 from the 'Authenticated User Redirect' drop-down field as shown in Figure 9.

b. In the 'User ID Mapping' section, supply the following values:

      • User ID Mapping – select AuthenticatedUserID. 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

b. 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 RSASHA256(RS256) or HMACSHA256(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 Figure 10 for an example.

FIGURE 10. OIDC Settings

c. 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 Figure 11.

FIGURE 11. OIDC - Scopes Settings

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

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

Refer to Figure 13 for an example.

FIGURE 13. OIDC - Client Details

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

g. Scroll down to the 'OpenID Connect/OAuth 2.0 - Client Redirect URIs' section and provide the following value:

FIGURE 15. OIDC - Client Redirect URIs Section

h. 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 ID1
      • Discoverable – Checked

An example is shown in Figure 17.

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.

  1. Log into Microsoft Azure.
  2. Click Azure Active Directory from left vertical menu.
  3. Click Security | Conditional Access.
  4. Click Manage | Custom Control.
  5. Click New custom control.
  6. Enter the JSON for customized controls as shown in Figure 18.

FIGURE 18. Conditional Access - Custom Controls

7. Supply the following values for JSON fields as shown in Figure 19:

    • App ID – enter the data applications that MSFT has referenced

FIGURE 19. JSON Field Assignments


Creating a New Policy

To create a new policy for this configuration in Conditional Access, follow these steps:

  1. Log into Microsoft Azure.
  2. Click on Azure Active Directory from left vertical menu.
  3. 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.

  • No labels