Security

Overview

This section details the different methods to authenticate WorkflowGen users, which are:

Choose one of these according to your needs and apply the required settings to implement it with your WorkflowGen instance.

Authentication methods

The WorkflowGen server and mobile applications can be configured to use OpenID Connect (OIDC) compliant or classic non-OIDC authentication methods. The following table shows the authentication methods supported by the different WorkflowGen applications:

* Except Microsoft Identity Platform v2.0.

OIDC compliant authentication methods

WorkflowGen can be configured to use the OpenID Connect (OIDC) compliant Microsoft Entra ID (formerly Azure Active Directory), AD FS 2016, Auth0, Okta, and Microsoft Identity Platform v2.0 authentication methods. The WorkflowGen Plus mobile app supports Microsoft Entra ID, AD FS 2016, Auth0, and Okta.

The legacy WorkflowGen mobile app does not support OIDC compliant authentication.

Classic authentication methods

See below for information and instructions on how to configure the classic non-OIDC Integrated Windows, IIS HTTP Basic, WorkflowGen HTTP Basic, Custom HTTP, and Form authentication methods.

Which classic authentication method to choose?

If you don’t know which authentication method to choose, follow the procedures below based on your situation:

  1. If all WorkflowGen users are managed in Active Directories, which is accessible from the web server hosting WorkflowGen, then you can choose one of these authentication modes:

    • Integrated Windows authentication (ensured by IIS)

    • IIS HTTP Basic authentication (ensured by IIS)

  2. If item 1 above applies to your situation, and you want to provide transparent authentication by using the current Windows session of the users, choose the following authentication mode:

    • Integrated Windows authentication (ensured by IIS)

  3. If item 1 above does not apply to your situation, and all WorkflowGen users are managed in an external application such a database or authenticated by a SSO solution, choose one of these authentication modes:

    • Custom HTTP Basic authentication (ensured by HttpModule)

    • Form authentication (ensured by .NET)

  4. If neither item 1 nor item 3 applies to your situation because you do not have any directory or other authentication solutions, you can choose only the following authentication mode:

    • WorkflowGen HTTP Basic authentication (ensured by HttpModule)

For all HTTP basic and form authentication modes, it is strongly recommended to use SSL because passwords are not encrypted.

Integrated Windows authentication

IIS and WorkflowGen settings

  1. Open the WorkflowGen Configuration Panel. In the Authentication section on the General tab, select IIS mode.

  2. Enable Integrated Windows authentication access on the WorkflowGen website and disable all built-in access mechanisms. Apply this setting on all sub-applications except the graphql and ws applications.

IIS HTTP Basic authentication

IIS and WorkflowGen settings

  1. Open the WorkflowGen Configuration Panel. In the Authentication section on the General tab, select IIS mode.

  2. Enable Basic authentication access on the WorkflowGen website and disable all built-in access mechanisms. Apply this setting to all sub-applications.

WorkflowGen HTTP Basic authentication

IIS and WorkflowGen settings

  1. To use WorkflowGen authentication, ensure that the directories have the Passwords are managed by WorkflowGen option selected, which allows you to set up a password for each user. Ensure that your current user has a WorkflowGen password associated with it, or you will be locked out.

  2. Open the WorkflowGen Configuration Panel and change the settings in the Authentication section on the General tab as follows:

    1. Set Mode to WorkflowGen.

    2. Choose your password management mode: Version 5 uses the same password management mode as earlier versions of WorkflowGen, while One-way Hashing stores hashed account passwords in the WorkflowGen database, which provides enhanced security.

    3. Set the maximum number of failed login attempts before a user’s account is locked.

    4. Set the minimum number of characters for a password.

  3. In IIS, enable anonymous access on the WorkflowGen website and disable all built-in access mechanisms. Apply this setting to all sub-applications.

  4. The Advantys.My.dll and Advantys.Security.dll assemblies must be copied to the \bin folders of your web forms. Your web services must continue to use Basic or Integrated Authentication.

  5. Optionally, you can activate the user logout link in the User Portal and Administration Module menus by setting an application session timeout in the web.config file. This will expire the user session in case of inactivity after a period of time (in minutes) as specified by the value of the ApplicationSessionTimeOut configuration parameter. For example, to set the user session to expire after 30 minutes of inactivity, modify the parameter as follows: <add key="ApplicationSessionTimeOut" value="30" />.

If you're using IIS 8 and above using an application pool in Classic Managed Pipeline Mode, the following will be added to your \wfgen\web.config:

<configuration>
    <system.web>
        <httpModules>
            <add name="ApplicationSecurityAuthenticationModule" type="Advantys.Security.Http.AuthenticationModule" />
        </httpModules>
    </system.web>
</configuration>

If you're using IIS 8 and above using an application pool in Integrated Managed Pipeline Mode, the following will be added to your \wfgen\web.config:

<configuration>
    <system.webServer>
        <modules>
            <add name="ApplicationSecurityAuthenticationModule" type="Advantys.Security.Http.AuthenticationModule" />
        </modules>
    </system.webServer>
</configuration>

Custom HTTP Basic authentication

IIS and WorkflowGen settings

  1. Using the sample code in the Sample code for an HTTP module section in the WorkflowGen Integration Guide, create a new class for the HTTP module you are creating.

  2. Modify the sample code to validate the credentials passed over HTTP Basic against the external configuration repository.

  3. Build your module and copy the assembly DLL into the \wfgen\bin and \wfgen\wfapps\webforms\bin folders.

  4. Your assembly DLL must be copied to all \bin folders of your web forms. Your web services can use Basic or Integrated authentication, or your custom HTTP Module.

  5. Open the WorkflowGen Configuration Panel and change the settings in the Authentication section as follows:

    1. Set Mode to Applicative.

    2. Set Method to Custom.

    3. Enter the assembly full name (namespace and class name) of the HTTP module (e.g. MyCompany.Hosting.Samples.CustomAuthModule).

  6. Enable anonymous access on the WorkflowGen website and disable all built-in access mechanisms. Apply this setting on all sub-applications.

If you're using IIS 8 and above using an application pool in Classic Managed Pipeline Mode, the following will be added to your \wfgen\web.config:

<configuration>
    <system.web>
        <httpModules>
            <add name="ApplicationSecurityAuthenticationModule" type="MyCompany.Hosting.Samples.CustomAuthModule" />
        </httpModules>
    </system.web>
</configuration>

If you're using IIS 8 and above using an application pool in Integrated Managed Pipeline Mode, the following will be added to your \wfgen\web.config:

<configuration>
    <system.webServer>
        <modules>
            <add name="ApplicationSecurityAuthenticationModule" type="MyCompany.Hosting.Samples.CustomAuthModule" />
        </modules>
    </system.webServer>
</configuration>

Form authentication

IIS and WorkflowGen settings

  1. Modify the login.aspx code to validate the credentials passed over HTTP Basic against the external configuration repository. If you don’t have any external configuration repository, you can add users directly in the web.config of WorkflowGen (refer to the .NET documentation).

  2. The login.aspx file must be copied to all of your webforms folders. This should only be applied to webforms. Web services must continue to use either Basic or Integrated authentication and therefore the login.aspx page cannot be used for them.

  3. In the WorkflowGen web.config file, register the authentication form:

    <configuration>
        <system.web>
            <authentication mode="Forms">
                <forms name="401kApp" timeout="30" loginUrl="/wfgen/login.aspx" cookieless="AutoDetect" defaultUrl="/wfgen/default.aspx" protection="None" />
            </authentication>
            <authorization>
                <deny users="?" />
            </authorization>
        </system.web>
    </configuration>

    ✏️ Note: Set the protection="None" or protection="All" attribute under the "forms" node. If "All" is used, the machineKey attribute and value must be added as well. (For more information about form-based authentication, see http://quickstarts.asp.net/QuickStartv20/aspnet/doc/security/formsauth.aspx.)

  4. Set the authentication to Windows for each WorkflowGen web service application web.config file and reset the security settings to Basic or Integrated in IIS for these folders.

  5. Enable anonymous access on the WorkflowGen website and disable all built-in access mechanisms. Apply this setting on all sub-applications.

FIPS compliance configuration

As of version 7.10.0, WorkflowGen is FIPS compliant and compatible with Windows FIPS compliant mode. If you want to enable FIPS compliance in your Windows environment, you have to configure the configuration password management and user password management modes beforehand.

Configuration password management mode

In the Security section on the Configuration Panel General tab, set Configuration password management mode to AES (FIPS Compliant) and enter a 32-character encryption key. When you click Save, the application passwords will automatically be converted to the new symmetric encryption mode.

User password management mode

In the Authentication section on the Configuration Panel General tab, set Password management mode to One-way Hashing (SHA256 FIPS Compliant) mode.

  • If you're using applicative authentication in Version 5 (Legacy) password management mode, users' passwords will automatically be converted into One-way Hashing (SHA256 FIPS Compliant) the next time they log in to WorkflowGen.

  • If you're using applicative authentication in One-way Hashing (SHA256) password management mode:

    1. Select IIS authentication mode.

    2. Select One-way Hashing (SHA256 FIPS Compliant) password management mode, then click Save.

    3. Re-enter all user passwords.

    4. Reset the authentication mode to applicative.

HTTPS: Using SSL with WorkflowGen

Overview

This section describes how to configure WorkflowGen to use SSL connection security level on the website.

IIS configuration

Activate SSL authentication for your WorkflowGen website.

Application parameters to update

You must update the following parameter in the WorkflowGen configuration (click on the Configuration Panel from the Administration Module home page):

  • Web application URL: you must update the protocol of the base URL of the application to https://.

Change the links to WorkflowGen to use https:// instead of http://.

Cross-origin resource sharing (CORS)

In order to allow a client application (such as front-end JavaScript code from an outside domain) to access and request data, you must enable and configure the Cross-origin resource sharing (CORS) settings. To do this:

  1. Install the IIS CORS Module on the WorkflowGen web server.

  2. Add the cors node with the list of external domains and their methods and headers (where HTTP requests will be allowed) to the WorkflowGen web configuration settings (located in \wfgen\web.config). See some common examples below.

📌 Example 1: Allow all origins

<configuration>
    <system.webServer>
        <cors enabled="true">
            <add origin="*">
                <allowMethods>
                    <add method="GET" />
                    <add method="POST" />
                    <add method="OPTIONS" />
                    <add method="HEAD" />
                </allowMethods>
                <allowHeaders>
                    <add header="Accept" />
                    <add header="Origin" />
                    <add header="Authorization" />
                    <add header="Content-Type" />
                </allowHeaders>
            </add>
        </cors>
    </system.webServer>
</configuration>

📌 Example 2: Allow specific origins

<configuration>
    <system.webServer>
        <cors enabled="true">
            <add origin="https://domain.b.com" allowCredentials="true">
                <allowMethods>
                    <add method="GET" />
                    <add method="POST" />
                    <add method="OPTIONS" />
                    <add method="HEAD" />
                </allowMethods>
                <allowHeaders>
                    <add header="Accept" />
                    <add header="Origin" />
                    <add header="Authorization" />
                    <add header="Content-Type" />
                </allowHeaders>
            </add>
            <add origin="https://domain.c.com" allowCredentials="true">
                <allowMethods>
                    <add method="GET" />
                    <add method="POST" />
                    <add method="OPTIONS" />
                    <add method="HEAD" />
                </allowMethods>
                <allowHeaders>
                    <add header="Accept" />
                    <add header="Origin" />
                    <add header="Authorization" />
                    <add header="Content-Type" />
                </allowHeaders>
            </add>
        </cors>
    </system.webServer>
</configuration>

For more information about the CORS configuration, see the IIS CORS module Configuration Reference.

Last updated