1.3.3.1. Authentication
- wiki
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 and Azure 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 or Google Auth.
Active Directory
- select an image for the provider
- insert an App name (visible on Flowster Portal and Flowster 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.
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
- 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
- Client ID needs to be taken from the application configured within google itself
- Client secret needs to be taken from the application configured within google
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.
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 or Google).
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:
