When talking about the Workflow Server security system, we indicate the following three components:
The settings related with security are edited in the following locations
The types of access to the admin panel.
Administrator login - only one person has access to the admin panel - a special user.
Administrator password.
The User interface is quite simple.
1 - the search filter. 2 - the list of Users, double click opens the User card.
The user editing interface is also very simple.
There are four main ways to create Users in the Workflow Server:
User import settings via LDAP are in the Dashboard page - in the Security tab.
If you configure the connection to LDAP, the Import from AD button will appear in the User interface; clicking on it, you can import Users. In this case, User groups are registered as the roles of these Users.
For each form, 4 access parameters can be set.
Available options:
If the access type value is not specified, then the default value is taken, which can be changed in the Dashboard page - in the Security tab.
There are two possible options. By default, access to forms is granted even for unauthorized Users, or exceptionally for authorized Users.
To authenticate Users,Identity Server 4, running inside the Workflow Server is used. Authentication can be performed both by login and password and through external sources that support OpenId (Facebook, Google, Okta etc).
To ensure correct authentication settings, it is very important to fill in URLs for redirects. The settings are in the Dashboard page - in the Security tab.
Redirect check settings. When a User logs 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.
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.
Warning! If you change any of these settings, the server instance must be physically restarted. That is, the Workflow Server application should be stopped and then restarted.
By default, the Identity Server is launched when a Workflow Server instance is started within that instance. However, for some instances, the Identity Server can be disabled. To do this, add the following to the config file:
{
"DisableIdentityServer" : true
}
Used to provide a web page with access to resources from another domain.
Adjusted parameters:
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)