<< Click to Display Table of Contents >>

Navigation:  Bizagi Studio > Security definition > Work Portal Security >



The Security module in Bizagi includes an Authentication component that has great versatility in user management and validation.

You may choose the type of Authentication from a series of possibilities that can be used by your Work Portal, according to your company's needs.




Types of Authentication

The following list briefly describes how the authentication types work in Bizagi.

Notice that some of the authentication types are specific to the platform in which you are running your Bizagi processes.


By default, a project in Bizagi will start using Bizagi authentication. For further information about each type of authentication, or to view and change this setting, refer to the links of the different authentication types.


Bizagi Authentication: Allows Bizagi to handle authentication itself (domain, users and their passwords are stored in Bizagi).


LDAP Authentication: Uses an LDAP Server (i.e Active Directory) to verify the information entered in the login page (username, password and domain).

While using authentication against an LDAP Server, passwords are not stored in Bizagi.


Federated Authentication: Uses an Identity provider that authenticates the user and facilitate Single Sign-On capabilities through federated services.

While using Federated authentication, passwords are not stored in Bizagi and the authentication in Bizagi is entrusted to that Identity provider which needs to comply with the WS-Federation Passive Protocol standard (i.e Active Directory Federation Services).

It is important to note that using ADFS demands management on your side regarding certificates to sign off assertions.

This means that you need to use certificates which are valid to the date, and watch after their expiration/renewal (most often these expire on a yearly basis).



Windows Authentication: Allows Bizagi to validate users against domains and Windows machines automatically.

This is done by having the Work Portal delegate the authentication to the windows machine on the client side (passwords will not be stored in Bizagi).

You may also have Bizagi take the Windows session credentials automatically and avoid a login page (achieve a SSO experience).


Custom Authentication: Allows the authentication to be handled by an external application.

With custom authentication, you develop your own component which overrides the methods by Bizagi in its Authentication component.

This way and by itself, the component you develop may rely on any APIs or other third-party components and connections to authenticate the user (i.e. validate against a MySQL database, XML files, a legacy system's database, etc).


Mixed Authentication: Allows using two different types of authentication for users from different domains. One of the types must be Bizagi Authentication, and the other type may be either Windows or Custom Authentication.




Recall the following important aspects:


1. Authentication run on execution will require that any user wanting to log in to Bizagi is previously imported/created in Bizagi's database (even though, with certain authentication types, further information such as the password is not stored in Bizagi itself).


2. With any type of authentication, the default domain\admon system user should be kept as enabled, though this user should not be assigned to a specific end user and it should not be granted with rights to use Work portal menus and options.

Instead, it is recommended to define an explicitly assigned user for your business administrator, having the privileges to use admin menu options (i.e modify parameter entity values, manage your users, licenses, cases, etc).


3. When using a .NET platform, regardless of the authentication type used in Bizagi, you will need to enable the anonymous access to the Work portal.



Authentication in runtime

Due to standard security measures, detail on error messages regarding failed authentication attempts are not displayed at the Work portal (to the end user).

In a production environment, you will need to have your system administrator review the event log details.

In a development environment, you may enable a temporary key to speed up your implementation and testing.