1.3.3.1. Authentication

The Security → Authentication page can be reached by clicking the menu item.

On the Authentication page can be added multiple Active Directory domains (with or without a trust set between them), Google, Azure and OpenIDConnect providers.

By default, the domain where Flowster Studio engine is installed will be added and it will be of Active Directory type:

User Account Control

Active Directory Authentication types

Flowster Studio uses two values for the authentication type in the Active Directory entries: Secure and Secure Socket Layer.

The Secure one: requests secure authentication. When this flag is set, the WinNT provider uses NTLM to authenticate the client. Active Directory Domain Services uses Kerberos, and possibly NTLM, to authenticate the client. When the user name and password are a null reference (Nothing in Visual Basic), ADSI binds to the object using the security context of the calling thread, which is either the security context of the user account under which the application is running or of the client user account that the calling thread is impersonating.

The Secure Socket Layer one: Attaches a cryptographic signature to the message that both identifies the sender and ensures that the message has not been modified in transit. Active Directory Domain Services requires the Certificate Server be installed to support Secure Sockets Layer (SSL) encryption.

Active Directory supports both Kerberos and NTLM. Windows will first try Kerberos and if all the requirements are not met, it will fallback to NTLM.

Kerberos is the default authentication method for AD but it can fallback to NTLM in some cases, but that is handled by Windows itself. Kerberos is used every time a login to an AD is made.

As an example, accessing a file share by name like \server1\share would invoke Kerberos and should succeed given proper permission. But accessing same file share using IP address would invoke Kerberos first and fail (as there is no SPN for IP Address) and then fail over to NTLM.

Here are some links for a better understanding of how the two protocols are working:

https://msdn.microsoft.com/en-us/library/bb742516.aspx

https://blogs.msdn.microsoft.com/chiranth/2013/09/20/ntlm-want-to-know-how-it-works/

Add new Authentication Provider

A new authentication provider can be added by expanding the New Provider list and selecting the desired type: Active Directory, Azure AD, Google Auth or OpenIDConnect.

Add an Active Directory Provider

Active Directory

select an image for the provider
insert an App name (visible on Portal and Designer login)
insert an App display name (this will be seen in the domain selection dropdown, for example in security groups – add child)
insert a FQDN for the domain. This can also be the domain’s shortname (DEMO) or the full FQDN (DEMO.trust)
insert the domain’s Short Name
Select the AD site (optional): this parameter takes precedence over the controller name specified in the LDAP field
insert the LDAP connection string. It can contain just LDAP://FULL_DOMAIN_NAME or it can also contain the name of the controller
insert a user with rights on the desired domain
insert the password for the user, in order to connect to the desired domain
check the SSL option only if the given domain uses a Secure Connection. If checked, then also insert the Port in the LDAP field. For example, LDAP://FULL_DOMAIN_NAME :636
click Save changes in order to add the new domain.

When clicking the Save changes button, a connection attempt is done in order to verify the provided information. The verification includes the validity of the FQDN and credentials. Users are offered the possibility to test the connection to the provider by clicking the Test Connection button in the Details area.

Add a Google Provider

A Google type authentication can be added by following the next steps:

App name (visible on Portal and Designer login)
App display name (this will be seen in the domain selection drop-down, for example in security groups – add child)
Icon
Showatlogin will enable this authentication option in the Login screens for Portal and Designer. If not checked, the option won’t be available for selection
ClientID needs to be taken from the application configured within google itself
Clientsecret needs to be taken from the application configured within google

Add an Azure Provider

Azure API Permissions

Following API Permissions are needed to login via Azure and to configure the allowed users and groups in FLOWSTER Studio:

Microsoft Graph:

Permission	Type
Group.Read.All	Application
GroupMember.Read.All	Application
User.Read	Delegated
User.Read.All	Application
openid	Delegated
profile	Delegated
Directory.Read.All	Application

An Azure type authentication can be added by following the next steps:

App name (this will be seen when logging into Portal)
App display name (this will be seen in the domain selection drop-down, for example in security groups – add child)
Icon
Show at login will enable this authentication option in the Login screens for Portal and Designer. If not checked, the option won’t be available for selection
Tenant ID needs to be taken from the application configured within azure itself
Client ID needs to be taken from the application configured within azure itself
Client secret needs to be taken from the application configured within azure.

Users are offered the possibility to test the connection to the provider by clicking the Test Connection button in the Details area.

NOTE: in order to properly use the Google and Azure authentication types, it is mandatory to check if the callback URLs are correctly set in Administrator → Client Apps. Select the desired app and check in Specific Configuration the GoogleCallback and AzureCallback settings. By default, the installer will assign callback URLs to both Portal and WebApps.

The configured endpoints for the Google and Azure callback settings need to be inserted as well on Google and Azure pages, at redirect URIs.

NOTE: Azure is case sensitive.

Add an OpenID Connect Provider

An OpenIDConnect type authentication can be added by following the next steps:

App name (this will be seen when logging into Portal)
App display name (this will be seen in the domain selection drop-down, for example in security groups – add child)
Icon
Show at login will enable this authentication option in the Login screen only for Portal. If not checked, the option won’t be available for selection
Client id: the id for the client. Used to authenticate the client against the authorization server endpoint
Client Secret: the shared secret to use for authentication against the token endpoint
Redirect URI: the redirect URI to use, must be registered for the client at the OpenID Connect server
Scope: the scopes to ask for
Issuer: the ID of the token issuer. This enables metadata discovery which will override the configuration set up (if the openid scope is requested)
Token Endpoint: the URL to the token_endpoint (if issuer not set)
Authorization endpoint: the URL to the authorization_endpoint (if issuer is not set)
Logout EndPoint: needs to be taken from the application configured within OpenId Connect Provider itself
Revocation Endpoint: needs to be taken from the application configured within OpenId Connect Provider itself
User Info Endpoint: the URL to the User info endpoint (if issuer is not set)
JWKS URI: the URL that points to the JWK set (if issuer is not set and the openid scope is requested)
Base URL: BaseURL to be added to internal redirect. Set this to enable the client to be behind a proxy.

CAUTION: This authentication provider is not supported in Designer or WebApps, only in Portal

Here, the users have an example of configuring an OpenID Connect Provider:

In order to add an OpenID Provider, the users can configure a new application on https://www.miniorange.com/ .

After setting up the miniOrange server, the users should follow the next steps:

Login on the miniOrange server
Click on Apps
Click on Add Application
Select OAUTH/OIDC and click on Create App
Select OAuth2/OpenID Connect
Client Name: enter the name of your application
Redirect-URL: enter the url where you wish to redirect after succsessfull authentication from miniOrange (e.g https://ip:port/Callback)
Click Save

After the app is configured successfully, the users can see the fields needed for Flowster Authentication by clicking on Select (Actions tab) and select Edit.

Edit Authentication Provider

An authentication provider can be edited by selecting it and changing the desired information in the Details area.

There can be changed all the information given, for all authentication providers types (Active Directory, Azure, Google or OpenID Connect).

Click the Save changes button in order to save the new information.

Remove Authentication Provider

An authentication provider can be removed by selecting it and clicking the Delete button located near the provider's name:

Flowster Studio 5.3