Security Settings

General information

When talking about the Workflow Server security system, we indicate the following three components:

• access to the Workflow API. It is considered separately.
• access to the admin panel.
• access to the forms.

The settings related to security are edited in the following locations:

• in Settings section - in the Security tab.
• in the Users section.
• in each of the forms, separately.

Restricting Access to Admin Panel

1. The types of access to the admin panel:

   • None - the access is not checked.
   • Basic - by login and password.
   • OpenId Connect - by login and password, together with the built-in Identity Server.

2. Administrator login - only one person has access to the admin panel - a special user.

3. Administrator password.

Working with Users

The User interface is quite simple.

1. The list of Users, double click opens the User card.

The user editing interface is also very simple.

1. Roles can be assigned to a User, and then, checked in your workflow.
2. If you want the user to log in by login and password, which are stored (password as a hash) in the database, then you can specify them in the user card.

There are four main ways to create Users in the Workflow Server:

1. Creating and editing Users through the admin panel interface.
2. Creating and editing Users through the Workflow API.
3. Importing Users via LDAP.
4. Automatic User creation when logging in through external sources that support OpenId (Facebook, Google, Okta).

User might import settings via LDAP which are in the Setting page - in the Security tab.

If the connection to LDAP is configured, the Import from AD button will appear in the User interface; then clicking on it, you can import Users. In this case, User groups are registered as the roles of these Users.

info

Set the properties in the config.json file to encrypt the LDAP password in the database.

{
  //...
  "LdapEncryptPassword": true,
  "Salt": "someSecureSaltForEncryption",
  //...
}

Then restart the Workflow Server and save the LDAP settings through the admin panel. This will update the LDAP settings in your database.

Authorization Settings for Forms

For each form, four access parameters can be set.

• who can create a process/document, in the Workflow Server document = process, from the given form.
• who can view the process/document content through the form.
• who can edit the values of the process/document parameters through the form.
• who can delete the process/document.

Available options:

• Anonymous - anyone, even an unauthorized User.
• Authorized - any authorized User.
• Owner - the one who created the process/document.

If the access type value is not specified, then the default value is taken, which can be changed in the Settings page - in the Security tab.

There are two possible options. The access to forms is granted even for unauthorized users by default, or exceptionally for authorized Users.

Authentication Settings

Identity Server 4, running inside the Workflow Server is used to authenticate Users. Authentication can be performed both by login and password and through external sources that support OpenId (Facebook, Google, Okta and others).

It is very important to fill in URLs for redirects to ensure correct authentication settings. The options can be accessed by: 'Settings' -> in the 'Security' tab.

1. Authority Base Url - the identity server address, usually matches URL, where the Workflow Server is available. If it's not specified, the hostname of the local computer is used.
2. Frontend url - the front end address, a page to redirect after logging in by an external provider, if the return url parameter was not passed. It is added to the Allow Redirects list in the identity server. If the server is running in the Admin mode, this address will be used in the Forms section.

3. Certificate file - the path to the certificate for signing authorization tokens. If there is no certificate, it will be generated automatically, but that is not recommended.
4. Certificate password - the certificate password for signing authorization tokens.

Redirect check settings. When users logging in, the first redirect is to the page with the login form (built into the Workflow Server, or external), and then, the back redirect. It is necessary to inform the identity server(s) about the addresses it can receive requests from and the addresses it can redirect to after logout. Therefore, to ensure correct authentication in forms, Redirect hosts and Redirect urls should be specified.

5. Use host redirect validation - if active, then, to check the redirect, the scheme, host and port addresses specified in the Redirect Hosts array are used instead of the whole address.
6. Redirect hosts - a list of the hosts allowed for redirects.
7. Redirect urls - a list of the URLs allowed for redirects. By default, the values from the Frontend url field are used.

If you use the forms interface built into the Workflow Server, then its host must be registered in the Redirect hosts array, while * Redirect urls* are optional. But if you embed forms into your site, then the host of this site must be included in the Redirect hosts list, and the url of the page where you embed the form should be in the Redirect urls list. The reason is that the forms built into the Workflow Server have special pages formssignincallback.html and formssignoutcallback.html that manage redirects, and redirects are performed to them, not to a custom page. Therefore, if you use the forms built into the Workflow Server, you do not need to write the * Redirect url* for each page. However, it is possible to set the Use host redirect validation * checkbox; then, it is enough to specify * Redirect host only, even for embedded forms.

8. Facebook - ClientId and ClientSecret to login through Facebook.
9. Google - ClientId and ClientSecret to login through Google.
10. Okta - Issuer, ClientId and ClientSecret to login through Okta.

caution

If any of these settings are changed, the server instance must be physically restarted. That is, the Workflow Server application should be stopped and then restarted.

Disabling Identity Server

The Identity Server is launched when a Workflow Server instance is started within that instance by default. However, for some instances, the Identity Server can be disabled. To do this, add the following to the config file:

{
  "DisableIdentityServer": true
}

CORS (Cross-Origin Resource Sharing)

It is used to provide a web page with access to resources from another domain.

Adjusted parameters:

• Allow from origin - addresses to send requests, with allowed access to the Workflow Server, for example, to the Workflow API.

Custom OpenId Connect Providers

Custom OpenId Connect providers are connected using the WorkflowServerRuntime.RegisterOpenIdConnectProviders method. That is, you can only add them by customizing the Workflow Server code.

public void RegisterOpenIdConnectProviders(params Action<AuthenticationBuilder>[] registerActions)

Through WorkflowServerInitializer:

(bool success, IWebHost host) = initializer.BuildWebHost(workflowServer =>
{
    ...
    //Register your own Identity Providers:
    workflowServer.RegisterOpenIdConnectProviders(authBuilder =>
    {
        authBuilder.AddOpenIdConnect("Authentication scheme name", "Display name", options =>
        {
            // ... adjust Id, key, etc
            options.SignInScheme = IdentityServer4.IdentityServerConstants.ExternalCookieAuthenticationScheme;
        });
    });
});

You can use your own implementations of IExternalLogonService and IExternalCredentialsProcessor after registering them via the WorkflowServerRuntime methods:

public WorkflowServerRuntime SetExternalLogonService(IExternalLogonService externalLogonService)

public WorkflowServerRuntime SetExternalCredentialsProcessor(IExternalCredentialsProcessor externalCredentialsProcessor)