Work Portal Authentication

<< Click to Display Table of Contents >>

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

Work Portal Authentication


The Work Portal is a web application which lets each of your users perform their corresponding tasks and configurations. And as such, before working in the application, each user must identify theirself to the system so that only the expected people can perform such activities.

This concept of identifying a user to a system is known as Authentication. This section covers everything you need to know about Authentication and whatever you need to do to configure it according to your needs in Bizagi.


Authentication explained

Simply put, authentication is the process of confirming the identity of a user against a system. In other words, it determines whether someone or something is in fact who or what it claims itself to be.

This concept has its own meaning and utility in technology, where it provides access control for systems by checking if the credentials provided by a user match those stored beforehand in the database of authorized users (which can be handled in a variety of ways, as it is described in this section). The following image illustrates how a user requests resources from the Work Portal but he needs to be authenticated in order to be granted access to such resources.




Authentication is commonly confused with Authorization, and even though the concepts are related, they are rather different. Authentication is in charge of letting in or denying the access of a user to a system, while Authorization is responsible of letting a user do only whatever he is supposed to. For example, if assistants are allowed to review some information but not edit it, the Authorization module of the application is the one that handles such functionality.


Authentication alternatives for the Bizagi Work Portal



If you plan on using an authentication method different than Bizagi and you are performing a deployment to an environment with no users 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.


There are plenty of ways of implementing the Authentication system of the Work Portal, they are described here from a general stand point but in this sub-hierarchy of the User's Guide you can find additional information on each one of them.


The diagram below depicts the authentication alternatives for a Bizagi application hosted On Premises, it shows the type of user experience they offer and whether the method is recommended.




Federated authentication

This type of authentication delegates the responsibility of identifying and authenticating a user to a third-party configured server, as shown in the image below.




There are two supported protocols for federated authentication:

oSAML 2.0: With this protocol Bizagi delegates the authentication procedure to the third-party Identity Manager of your choice (Bizagi Supports integration with Azure AD, ADFS, NetIQ, Okta, PingFederate or SiteMinder) which will handle the information with secure messages through the SAML standard protocol. We encourage you to use this type of authentication since it is a widely adopted industry protocol that can be configured with multiple vendors. For more information about this method, refer to SAML authentication.

oWS-Federation: This type of authentication is done by delegating the information to an ADFS server that has been configured to work with this protocol. The messages are sent using the WS-Federation and WS-Trust standards which uses SAML 1.1 assertions, which are not SAML 2.0 Compliant. For more information about this method, refer to WS-Federation.



Although for federated authentication there are two supported protocols. We recommend using SAML 2.0 over WS-Federation. SAML 2.0 is a common standard in the industry that can be compatible with a full range of systems in your organization.


Windows authentication: This type 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 log in page (achieve a SSO experience at a network level). For more information about this alternative, refer to Windows Authentication. It is recommended to use this alternative when your organization already counts with a Windows authentication system.


OAuth: This type of authentication uses the OAuth and OpenID Connect protocols for your Bizagi project to delegate authentication to an identity provider such as another Bizagi project. For more information about this alternative, refer to OAuth authentication.


LDAP Authentication: This type of authentication supports integration with an on-premises Microsoft AD and it relies on standard LDAP protocol (e.g, connecting via an LDAP URL with filters as supported by LDAP format). It offers a "Same Sign-On" user experience. For more information about this alternative, refer to LDAP authentication.


Bizagi authentication: This type of authentication uses Bizagi's local authentication mechanism, while allowing you to enforce your security policies for passwords and accounts. For more information about this alternative, refer to Bizagi authentication.


oMixed authentication: This type of authentication allows you to use two different types of authentication in order to handle external and internal users. One of the types must be Bizagi Authentication; and the other type may be either Windows or Custom Authentication. This is the recommended alternative for those cases where you are going to have business and external users on your application. For more information about this alternative, refer to Mixed Authentication.


Custom authentication: This alternative enables 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). For more information about this alternative, refer to Custom Authentication.


Authentication user experience alternatives

There are two notable user experiences when talking about authentication. Each one of them have different characteristics and are a consequence of the nature of the authentication alternative that has been configured.


Single sign-on is the concept of authenticating yourself once and get access to all of the the applications that share the same authentication method and third-party server.




Same sign-on refers to using the same user credentials in each of the log in screens of the applications a user needs have access to.




Authentication methods summary

The following table describes the most important characteristics of each authentication method, from the perspective of what you can do with it from Bizagi.




Single sign-on

Same sign-on

When to use it

SAML 2.0 Federated authentication

If you have an IdP


If your IdP does not support SAML 2.0

Windows Authentication

Depends on if you are on the intranet or not

When you don't have an IdP

OAuth2 - OpenID

When federated authentication is not an option


When Windows Authentication is not an option


If you want users and credentials to be managed independently by Bizagi


Depends on the selected methods

Depends on the selected methods

If your use case needs business and external users


Depends on what you configure

When there is no other option



Please bear in mind the following:

1.It is the customer's responsibility to manage end user accounts and their access to Bizagi's Work portal. It is the customer's responsibility to make sure settings that enforce adequate security policies for these accounts and their passwords.

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 integrating an Identity Manager, and regardless of the chosen one, customers need to synchronize the accounts that are authorized to access Bizagi's Work portal.

Synchronizing means inserting or updating the account's primary identifier only (domain plus username typically, and the e-mail) in Bizagi.

Recall that passwords are not stored in Bizagi when integrating an Identity Manager.



Synchronizing users is a task which may be scheduled in Bizagi, by having it connect to your AD.

Alternate options to an AD/LDAP sync consider invoking Bizagi web services from your end (a "push"), or having Bizagi invoke a web service on your side to fetch users (a "pull").


There are alternative ways of populating your users information, refer to these articles for further information:

Importing LDAP Users.

Synchronizing users via web services.

How to synchronize users from an excel file.


If you will not synchronize users about yet, then you may test that the authentication works as expected by simply creating one user manually in Bizagi Work portal for validation purposes.


Authentication for multiple domains

If your project uses more than one domain, you can configure Multiple Authentication, you can use several authentication types and domains in your Bizagi solution. A domain refers to a specific group of users who share common parameters such as their location, area, corporation, among others.





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.

Through this module, authentication may be set up with Bizagi Studio; or similarly through the Management Console for live environments (e.g, testing or production).








Every time you make changes in the authentication configuration in Bizagi Studio or the Management Console, it is necessary to reset your application server or IIS.


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.