Microsoft Azure AD - Enabling conditional access with inWebo OpenID

It is highly advisable to add additional security and verification to the access of your organization's critical applications, such as financial and employee data apps, intellectual property storage apps and so on. With the inWebo Azure Active Directory plugin inWebo authentication can be used to provide strong verification for your applications' access by adding a conditional access policy to your Azure Active Directory.


  • Azure Directory account at a Premium level (P1 or P2)

  • An inWebo account (could be a Trial Account)

  • Register with inWebo to enable the inWebo Azure AD connector in your tenant

inWebo Azure AD connector configuration

Create an inWebo “OIDC Azure AD” Connector

You have to indicate the content for the following fields to register your inWebo Azure AD Connector:

  • Connector name: A chosen name / information to define this connector's goal in the administration console. The name of the connector will be used to create the secure site, so it will appear in the authentication context sentence

  • Client ID: The client ID allows the junction between the inWebo connector and the Azure AD custom control (when creating the custom control, specifies this value of ClientId in the JSON code).

  • Client Secret: is not used for the Azure AD (this value is defined for OpenID Connect standards)

  • Authentication URL: indicates the chosen authentication page (with VA, Helium, mAccess Web or Authenticator App) as indicated below

  • Custom claims: It is necessary to check that the claim shown is present (InWeboMFa - Static - MfaDone), this value is predefined in the custom control for Azure AD.

Possible authentication page used by inWebo Azure AD connector:

For all connectors created before April 15, 2021, the authentication page is one of the following:

Select the type of authentication mode you have decided to provide to your users when accessing your secure content. It provides the user with a first mode of authentication on arrival but is not exclusive as other modes are still available.

Note: after creation you can edit parameters, for example you can still change the Authentication URL.

For connectors created after April 15, 2021, the authentication page is one of the following:

  • Helium -

  • Virtual Authenticator -

  • mAccess Web -

  • inWebo Authenticator App

Note: We recommend for all connectors created before April 15, 2021, to modify the URL of the authentication page in order to use the domain as described above.


Connector's preview after creation

  • secure aliases and site aliases have been generated automatically.

  • Copy the generated "Connector alias" value and "Client ID" in a document for later use

Secure site configuration

A secure site is automatically created after the previous Azure AD connector configuration,

Warning: specific Secure site configuration for Azure AD as of April 15, 2021

Mandatory secure site configuration - see below

The secure site that is created by default after the creation of an Azure AD connector looks like this:

In addition, please create a second secure site of the same type with the following parameters:

The only difference is the Called URL parameter, that has to be set to (for example using the va page).

Obtaining the inWebo Azure AD Json code

To obtain the inWebo Azure AD Json code for your Azure AD configuration you can click on the link at the bottom of the connector configuration menu.  
"Display json code for Azure custom control"

Sample of provided inWebo Json Code

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 { "Name": "Name of your AZURE service", "AppId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx", "ClientId": "xxxx openId client identifier xxxx", "DiscoveryUrl": "", "Controls": [ { "Id": "RequireInWeboMfa", "Name": "RequireInWeboMfa", "ClaimsRequested": [ { "Type": "InWeboMfa", "Value": "MfaDone", "Values": null } ], "Claims": null } ] }

To be noted

The "Id": "RequireInWeboMfa", "Name": "RequireInWeboMfa" fields must be unique, they must not be used by other "custom control" mechanisms.
However, you can change the "Name" field to "Require inWebo MFA service name" for a more meaningful display by adding the name of the related inWebo service for Azure AD.

Creating your custom controls in Azure AD

To add inWebo multi-factor authentication you have to create the Azure AD custom controls with this procedure

  • As an Administrator, access your Microsoft Azure AD tenant with the Microsoft Azure Portal

  • Select "More Services", browse to "Identity" category and select "Azure AD Conditional Access"

  • In the Conditional Access menu select "Custom controls (preview)"

  • At the top of the displayed page, click on the "+" next to "New Custom Control"

  • In this page, delete the existing code and copy-paste the inWebo Json code provided by inWebo

  • click "Create"

Creating the conditional access policies

You can control how authorized users can access your cloud apps.
The objective of a conditional access policy is to enforce additional access controls on an access attempt to a cloud app based on how an access attempt is performed.

  • At the top of the Conditional access Menu select "Policies"

  • At the top of the displayed page, click on the "+" next to "New policy"

  • Name your new Policy i.e "inWebo Authentication"

  • Assign impacted Users groups and App following your own specifications.
    (When testing it is recommended to not apply this policy on your own Administrator, but to test it on a limited group of users at first to verify your authentication mechanism.)

  • Under the "Access controls" section, select "Grant"

  • At the top of the displayed page select "Grant access", make sure "require Multi-factor authentication" is not checked (this is Microsoft MFA), scroll down and select the custom control ID: "RequireInWeboMfa".

  • Then make sure "Enable Policy" is On at the bottom of the left column.

Using both sAMAccountName and UPN

If Azure AD is your first use case with inWebo, you will probably use the UPN directly as an inWebo login. But if you were already using the sAMAccountName as a login for your legacy applications, you have two options:

  • If the email field of your users contains the UPN, choose Login Type = Email in the Azure AD connector.

  • You can also provision the UPN in the Alternative Login field, and choose Login Type = Alternative Login.

New feature coming soon:
- The provisioning of the Alternative Login will be performed with IWDS (inWebo Directory Sync).

Additional references