Windows authentication

<< Click to Display Table of Contents >>

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

Windows authentication


When using Windows authentication in Bizagi, the Work Portal delegates the authentication to the Windows machine on the client's side (by relying on the Windows session which should be already validated against a domain).


With Windows authentication, a successful login happens if the Windows session is valid and if the user is already created in Bizagi Work Portal (passwords are not stored in Bizagi).


Since Windows authentication is a type of integrated authentication, there is a Single Sign-On experience when accessing from Windows OS which belong to the corporate domain (being authenticated with a valid session with that same domain).

This means that the login page will be automatically skipped.

When otherwise (accessing from a different domain, or a non-Windows OS or a mobile device), then users will need to explicitly input their credentials.



This feature is not eligible for Automation Service.

Potential advantages offered by the use of Windows authentication are not applicable due to the fact that underlying infrastructure of Automation Service is not included in your corporate domain.

For integrated authentication possibilities with your identity provider systems, while relying on top security measures and a SSO experience, it is recommended to use an ADFS or Azure AD in Automation Service.




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.



When using Windows authentication, make sure:

1. That you Bizagi Work Portal configuration in the IIS, enables the Anonymous authentication and Windows authentication. (See Note on the bottom of the page)

2. That browsers accessing Bizagi Work Portal support Windows authentication as implemented by Microsoft.

This means that browsers in turn need to rely on certain standards which allow for a Single Sign-On experience oriented to Windows authentication (these type of authentication does not use cookies).

Such standards can include:

IWA (Integrated Windows Authentication).

Its support allows you to skip an intermediate Bizagi login page.

HTTP Negotiate authentication.

NT Authentication.

NTLM Authentication.

Domain authentication.

Windows NT Challenge/Response Authentication.



When not all of your users are registered in the local or corporate domain, it is recommend to rely on an additional type of authentication.

Keep in mind that for such scenario, you may use Windows authentication alongside a local Bizagi authentication through the Mixed authentication option.


Setting Windows Authentication

To set Windows as the authentication type, select Windows from the drop-down list:




Click on the Update button.




Fill in or configure these settings:

Cookie type: Define the type of cookie Bizagi uses Persistent o Session cookies. The idle session time-out defines the expiration time for cookies.

Enable authentication logging in database: Check this checkbox (set to On) to direct the web application to log every authentication event, according to your auditing requirements and expectations. You can view the log in the Work Portal.

Enable multiple factor authentication: Establish if the project uses multiple factor authentication.

Idle sessions time-out: Define the minutes of inactivity after which a session expires, according to your authentication requirements and expectations (e.g, 5 minutes).

Show detailed authentication error messages: Check this box if you want authentication errors to be shown in a detailed way when they occur.


By default, with this configuration Bizagi Work Portal will show the login page but validate access if the session is valid.


If you wish to skip the login page and have Bizagi automatically take the Windows session's credentials, you will need to carry out additional steps at the Web server (IIS) and for the browsers, as described in the next section.


Login page

When using Windows authentication or Mixed authentication (with Windows authentication enabled), by default Bizagi will skip the login page.

This is automatically done if the user is a registered Bizagi user and he/she is logged in to the intranet authenticating with Windows credentials.

If the above condition is not met, then the login page is presented.


The above also implies that Windows authentication has priority over Bizagi authentication (meaning that Windows credentials are automatically first identified for log in).



In some browsers such as IE, and according to your corporate browser configuration settings and policies, you may need further configuration to make sure that credentials are automatically taken or input them for a first time.


Logout considerations

When using Windows Authentication, the logout is not done by Bizagi Work Portal, as the web browser automatically sends the user's credentials from the active Windows session to IIS.


Preventing re-login or automatic submission of user credentials depends on the browser settings and cannot be configured on the server-side. This authentication method is known as Integrated Windows Authentication IWA.


User credentials are not sent to IIS in the following cases:

1.The browser is in incognito mode, and the user has not been logged in to the Work Portal for the first time.

2.The browser or the operating system configuration requires credentials not to be sent automatically.


Find more information on how to disable automatic submission of user credentials here:


Importing 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 Identity provider into Bizagi.

For more information about this option, refer to Synchronizing 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.