Azure AD Authentication

Overview

This section provides instructions on how to configure WorkflowGen delegated authentication with Azure AD authentication API endpoint v1, and will show you how to set up a working WorkflowGen instance that uses Azure to authenticate your users.

In the instructions, substitute <workflowgen url> with the domain and path to your WorkflowGen instance; for example, localhost/wfgen or www.mycompany.com/wfgen.

Prerequisites

  • Make sure to have a licensed copy of WorkflowGen installed and running on a server. You must be a WorkflowGen administrator.

  • Make sure to have Azure AD administrator access to be able to configure Azure AD.

  • Make sure to have provisioned an existing Azure AD user that you can authenticate with to WorkflowGen and that the user has administrator privileges. This is important because once you've activated the delegation, you'll still need to be able to manage the application.

  • AES encryption mode and its key are required for the authentication to work.

Azure Active Directory configuration

The configuration of Azure AD is done in two parts. First, you have to register the WorkflowGen web application and link it to your instance of WorkflowGen; then, you have to register the WorkflowGen GraphQL API to be able to register custom applications to access it.

Step 1: Create a new application registration for WorkflowGen

  1. In the Azure portal, click App registrations in the Azure Active Directory section.

  2. Click New registration, and fill in the properties form:

    • Name: WorkflowGen Web app

    • Supported account type: Account in this organizational directory only

    • Redirect URI:

      • Type: Web

      • Value: https://<workflowgen url>/auth/callback

      ✏️ Note: Depending on the context, you should choose the right option for your use case for the Supported account type value. 📌 Example: https://mycompany.com/wfgen/auth/callback

  3. Click Register at the bottom of the page.

You should now see the WorkflowGen registered application's overview page.

Step 2: Create a client secret for the application

Now, you have to generate a client secret to use in the WorkflowGen Authentication Module.

  1. Click Certificates & secrets.

  2. In the Client secrets section, add a new client secret.

    • DESCRIPTION: secret, or something to know that this is the client secret.

    • EXPIRES: Choose Never.

    • VALUE: Anything with sufficient entropy that it can't be guessed, such as a UUID.

  3. Click Save. The value you entered will now be encrypted.

  4. Save the generated value, since you won't be able to retrieve it afterwards.

Step 3: Add a redirect URI

In order for the communication between WorkflowGen and Azure to work, you need to add one more authorized redirect URI to the registered WorkflowGen Web app web application.

  1. Click Authentication.

  2. In the Redirect URIs section, enter the following information:

    • Type: Web

    • Redirect URI: https://<workflowgen url>/auth/logout/return 📌 Example: https://mycompany.com/wfgen/auth/logout/return ✏️ Note: You should also see https://<workflowgen url>/auth/callback in this list.

  3. Click Save at the top of the section.

Step 4: Create a new application registration for the WorkflowGen GraphQL API

In order to expose the GraphQL API, you need to add a new application that will represent it. To do this:

  1. In the Azure portal, click App registrations in the Azure Active Directory section.

  2. Click New registration, and fill in the properties form:

    • Name: WorkflowGen GraphQL

    • Supported account type: Account in this organizational directory only

  3. Click Register at the bottom of the page.

You've now successfully registered the GraphQL API in Azure AD.

Step 5: Expose the API in the WorkflowGen GraphQL API application registration

  1. Click Expose an API.

  2. To the right of Application ID URI, click Set and enter the URI https://<workflowgen url>/graphql. 📌 Example: https://mycompany.com/wfgen/graphql

  3. Click Add a scope and enter the following information:

    • Scope name: default

    • Who can consent?: Admins and users

    • Admin consent display name: Default access to the GraphQL API

    • Admin consent description: Allows the application to get access to WorkflowGen's GraphQL API.

    • User consent display name: Use the admin consent display name

    • User consent description: Use the admin consent description

  4. Click Add scope.

  5. Click Save.

Since October 2021, Azure AD requires the use of a default schema or a verified domain for the AppId URL on single tenant application (see the Microsoft documentation here for more information). The Microsoft documentation on how to add and verify a custom domain is available here.

Step 6: Give access to WorkflowGen

  1. On the WorkflowGen application registration page, click API permissions.

  2. Click Add a permission, then My APIs.

  3. Click WorkflowGen GraphQL API in the list.

  4. Click Delegated permissions and check default.

  5. Click Add permissions.

Review the registrations

You should now have all of the information you need to configure WorkflowGen to delegate authentication to Azure AD. Here's a review:

  • A client ID. This is the application ID of the registered WorkflowGen app on Azure. You can find it on its overview page.

  • A client secret. This is the secret previously generated.

  • An audience. This is the Application ID URI property in the Expose an API section.

  • The metadata endpoint. This URL is bound to your Azure directory. To find it:

    1. Go to your directory properties section.

    2. Copy the Tenant ID value.

    3. The metadata endpoint is built like this: 

      https://login.microsoftonline.com/<Tenant ID>/.well-known/openid-configuratio

By now you should have all the information needed to link your WorkflowGen instance to Azure AD.

WorkflowGen configuration

Now, you have to configure WorkflowGen to delegate its authentication to Azure AD.

Step 1: Add Azure AD values to the WorkflowGen web.config

  1. Open the WorkflowGen web.config file and add the following properties under <appSettings>.

    <!-- Azure v1 auth -->
<add key="ApplicationSecurityAuthProvider" value="azure-v1"/>
<add key="ApplicationSecurityAuthClientId" value="<CLIENT ID>" />
<add key="ApplicationSecurityAuthClientSecret" value="<CLIENT SECRET>" />
<add key="ApplicationSecurityAuthMetadataUrl" value="<METADATA URL>" />
<add key="ApplicationSecurityAuthCheckSessionUrl" value="<CHECK SESSION URL>" />
<add key="ApplicationSecurityAuthAppIdClaim" value="appid" />
<add key="ApplicationSecurityAuthUsernameClaim" value="upn" />
<add key="ApplicationSecurityAuthClockTolerance" value="60" />
<add key="ApplicationSecurityAuthSessionRefreshEnableIFrame" value="Y"/>

  2. Replace <CLIENT ID> with the application ID.

  3. Replace <CLIENT SECRET> with the the WorkflowGen registered application's generated secret on Azure.

  4. Replace <METADATA URL> with the URL that you built earlier from the Tenant ID value of your Azure AD directory.

  5. Replace <CHECK SESSION URL> with the value of the metadata endpoint's check_session_iframe property. To do this, you'll have to make a request to the <METADATA URL>, then copy and paste the value. (See the table below for more information about this property.)

    Linux/macOS request example:

    curl "<METADATA URL>" | python -m json.tool

    ✏️ Note: Remove | python -m json.tool if you don't have Python; this is for pretty printing.

    Windows PowerShell request example:

    Invoke-RestMethod -Uri "<METADATA URL>" -Method GET | ConvertTo-JSON

Table of web.config options

Option

Description

ApplicationSecurityAuthProvider

The name of the identity provider supported by WorkflowGen. At this time, there is support only for Azure Active Directory, Auth0, AD FS, and Okta. Value: azure-v1, auth0, adfs, orokta

ApplicationSecurityAuthClientId

Each identity provider generates a code that uniquely identifies your application. In this case, this is the code that uniquely identifies the WorkflowGen web application.

ApplicationSecurityAuthClientSecret

Like the client ID, this is also generated by the identity provider, but it is more like what a password is for a user. It's important to keep this secret because malicious software that has access to this can act on the behalf of the application. This value must be explicitly generated in Azure Active Directory.

ApplicationSecurityAuthMetadataUrl

ApplicationSecurityAuthAppIdClaim

ApplicationSecurityAuthUsernameClaim

The name of the claim contained in the access token that identifies the user in WorkflowGen. This is used by WorkflowGen to generate a session token as well as by the GraphQL API when receiving an access token. ✏️ Note: It's recommended to keep the default value.

ApplicationSecurityAuthClockTolerance

This value is used when verifying a token in WorkflowGen. It's essentially to deal with minor differences between servers' clocks. ✏️ Note: It's recommended to keep the default value.

ApplicationSecurityAuthSessionRefreshEnableIFrame

When enabled (Y), this option activates the session auto-refresh feature using an invisible <iframe>. This allows users to enter their password less often by refreshing their session in the background while they're working.

✏️ Note: This option is only available when using WorkflowGen with OIDC authentication.

WorkflowGen is now linked to Azure AD and back. The last thing left to do is configure a few more options in order to finish the internal wiring of WorkflowGen so that it can delegate its authentication.

Step 2: Add security values for session generation

In order to generate a session token, you need to add a few more settings to the web.config.

  1. Open the WorkflowGen web.config file and add the following property under <appSettings>:

     <!-- Auth -->
 <add key="ApplicationSecurityAuthSessionTokenSigningSecret" value="<SECRET>" />

  2. Replace <SECRET> with a value that can't be guessed, such as a UUID.

The secret will be only accessible inside your instance of WorkflowGen, so when generating a session token, WorkflowGen will sign it with this secret in order to check the validity of all session tokens passed to it.

Step 3: Activate the authentication delegation

You now need to activate the delegation by replacing the authentication system in IIS and pointing WorkflowGen's modules to the correct authentication module.

Configure IIS

  1. In IIS Manager, click on the WorkflowGen application in the tree view.

  2. Click the Authentication button.

  3. Enable Anonymous Authentication, and disable all other authentications.

  4. Perform these steps for all sub-applications as well.

Add properties to the web.config files of certain modules

Certain modules need to have their authentication checked by the special Advantys.Security.JWTAuthenticationModule WorkflowGen authentication module, but certain other modules should not because they are either public or aren't part of the global authentication system.

  1. Add the following property to the WorkflowGen web.config file:

    <?xml version="1.0" encoding="UTF-8"?>
<configuration>
 <system.webServer>
     <modules>
         <add name="ApplicationSecurityAuthenticationModule" type="Advantys.Security.Http.JWTAuthenticationModule" />
     </modules>
 </system.webServer>
</configuration>

  2. If you have developed custom web forms with their own \bin folders, you have to copy the following .NET assemblies and dependency libraries from \wfgen\bin to each custom web form's \bin folder (\wfgen\wfapps\webforms\<custom webform>\bin):

    • Advantys.My.dll

    • Advantys.Security.dll

    • Newtonsoft.Json.dll

    • jose-jwt.dll

You should now have a working WorkflowGen instance with the authentication delegated to Azure AD through the OpenID Connect protocol. Make sure to have provisioned your users to WorkflowGen in order for them to successfully access WorkflowGen.

Additional information

SOAP services support

WorkflowGen only supports requests to the SOAP API using classic authentication methods. If you still need to use this API, you have to perform some additional steps to configure it properly:

  1. Create a new separate WorkflowGen directory (i.e. users and groups) for the SOAP API users.

  2. Provision it with users and groups as needed.

  3. In IIS Manager, enable the Basic authentication method for the \wfgen\ws application.

  4. In the web.config file (located in \Inetpub\wwwroot\wfgen), add the following under <location path="ws" inheritInChildApplications="false"> : 

    <system.webServer>
    <modules>
        <remove name="ApplicationSecurityAuthenticationModule" />
    </modules>
</system.webServer>

About session management

Azure Active Directory supports OpenID Connect Session Management, an extension draft standard, in addition to the core OpenID Connect standard. This standard defines the rules to handle SSO session of the provider from the client. An example use is that if a user logs out of their Azure AD session from any device, a regular web client will receive a message that enables it to remove the same user's local session. WorkflowGen supports this feature when activating delegated authentication with Azure AD.

Configurable options

This table lists all configurable options in WorkflowGen that you can use to customize your authentication experience; these are located in the WorkflowGen web.config file.

Option

Description

ApplicationSecurityAuthSessionTokenCookie

The name of the session cookie that is generated by the authentication module. Default: wfgen_token ✏️ Note: This is useful when you have multiple instances of WorkflowGen running and you want to have access to both and be authenticated on both instances at the same time.

ApplicationSecurityAuthSessionTimeOut

The duration of the session in seconds. It defaults to the ID token expiration time received. Default: the exp value of the ID token

ApplicationSecurityAuthMobileSessionTimeOut

The duration of the session in seconds when requested from mobile devices on the token endpoint. Default: 7200 seconds

Current limitations

  • If the WorkflowGen User Portal or Administration Module is displayed without the main header menu, this feature will not work. For example, this scenario could happen when the portal home page or a request follow-up form is displayed inside an iFrame in an external solution.

  • The GraphiQL module (/wfgen/graphql) doesn't support session management when displayed in a browser.

PreviousAzure AD SynchronizationNextAzure AD Configuration for Mobile Apps

Last updated