When using LDAP Authentication in Bizagi, credentials entered in the login page (username, password and domain) are sent to an LDAP Server for verification.
Once the server verifies and permits the access, login is successful as long as this user is already created in Bizagi.
In this authentication, passwords are never stored in Bizagi.
If you plan on using an authentication method different than Bizagi and you are performing a deployment to an environment with no user information on it (normally this would only be the case for a project's first deployment), follow these steps so that you can correctly configure your users and authentication without getting locked out of the Work Portal:
1.Perform the deployment with the authentication method set to Bizagi. This lets you access the Work Portal as the Admon user without providing any credentials.
2.Once in the Work Portal you can manually enter your users, or alternatively you can rely on the method of your choice to synchronize your users' information into the WFUser table (SOAP, Excel file, LDAP Synchronization, or performing a Data Synchronization procedure).
3.Perform an IISRESET so that the Admon user can no longer access the Work Portal.
4.After having your users registered in the Work Portal, use the Management Console to set the authentication method to your preferred one.
If you plan on using LDAP authentication with periodic users synchronization, you may ignore the previous steps since you will only need to wait until the next synchronization happens for your users to be able to log into the Work Portal.
Setting LDAP Authentication
To set LDAP as the authentication type, select LDAP from the drop-down list:
Click on the Update button.
The following options presented as inner items must be configured:
•Cookie type: Defines whether Bizagi uses Persistent o Session cookies. The idle session time-out defines the expiration time for cookies.
•Enable authentication logging: Establishes if an audit log is recorded with all authentication events. If enabled look for the table AUTHOLOG in the database.
•Idle session time-out: Defines the time in minutes in which an idle session expires; in which case it would be required to authenticate again. This setting defines the expiration time for cookies.
In case you wish to increment this time-out to more than 60 minutes (not recommended), bear in mind that you will need to edit the default settings at your web server (e.g, doing so directly at the IIS).
•LDAP URL: Corresponds to the path to access the LDAP Server (using the LDAP URL format).
It is mandatory that you input LDAP://.. with the starting LDAP prefix in uppercase, capital letters.
•Show detailed authentication error messages: Defines if authentication errors are shown in a detailed way when they occur.
•Use settings in LDAP synchronization: Applies if you already have configured Bizagi to synchronize your Active Directory users into Bizagi.
If this is the scenario, turn this option on, to use the same LDAP URL and settings from the LDAP synchronization settings.
When this option is on, the value of the former option will be ignored.
Windows Active Directory is supported as for LDAP authentication.
Note that it is necessary that the Web site configuration at the Server (i.e IIS), uses Anonymous authentication for the Work Portal.
Importing LDAP Users
For any type of authentication, you will need to make sure that users are created at Bizagi Work portal.
Disregarding the selected Authentication type for your Work Portal login, you may choose to configure a schedule in Bizagi to import and synchronize users from your LDAP Server into Bizagi.
For more information about this option, refer to Importing LDAP Users.
About Anonymous authentication
Bizagi's Engine, like any other modern web application, bases its architecture on thin clients that consume web services (REST) from the business logic layer.
Bizagi is fully committed with the security, and decides to take complete control of the way in which these services are secured. Through filters at the request level, and with validations in every single service, the authentication and authorization modules of the Product guarantee that the different operations can only be executed by authorized users.
The static resources (html, js, css, images) that make up the login page must be exposed publicly and without restriction, only in those environments and configurations where it is necessary to display it: in the mobile application and in the web application when it is exposed to the Internet.
To achieve this, it is necessary to enable the anonymous authentication at the Internet Information Services, always keeping in mind that this configuration does not alter the security of the application, because Bizagi does not delegate the management of the authorization of its services to the IIS.