Configure the authentication parameters in Bizagi

<< Click to Display Table of Contents >>

Navigation:  Bizagi Studio > Security definition > Work Portal Security > Work Portal Authentication > WS-Federation authentication >

Configure the authentication parameters in Bizagi


Bizagi supports integration with an Identity provider to provide Federated authentication and Single Sign-On capabilities.

For more information about this type of authentication in Bizagi and its prerequisites, refer to Federated authentication.


Once you have configured your Identity provider, you may configure the authentication parameters in Bizagi.




Parameters configuration in Bizagi

Bizagi being a service provider in your Federated authentication setup, you will need to make sure you configure the necessary authentication parameters in your project.

When using federated authentication, you rely on the WS-Federation Passive Protocol (supported by Identity providers such as Active Directory Federation Services).


Using WS-Federation

When setting the use of WS-Federation in Bizagi, assertions will rely on the WS-Federation Passive Protocol standard.

To configure the authentication parameters in Bizagi for this scenario, carry out the following steps:



Before you move on, make sure you have already setup your Identity provider to work with Bizagi as presented in the ADFS configuration example.


1. Configure Federated authentication.

To do this in Bizagi Studio, go into the Expert View and locate the Security module.


Click on the Authentication option found under the Security item, and select Federated authentication from the drop-down list in the panel to the right:




Notice you will see this authentication relies on the WS-Federation protocol

Click Update.

You will get a confirmation message and notice that additional parameters appear under the Authentication item.


2. Configure further parameters.

Proceed to configure these additional parameters as described below, ensuring you click Update for each one that is modified.

Note that the parameter values are case-sensitive and therefore you will need to make sure you input these correctly.







Cookie Handler requires SSL

Enable or disable this parameter to rely on SSL when handling cookies.

This field is not mandatory.

Cookie Type

Select if the cookie generated by Bizagi is Persistent or based on Session.


Persistent cookies remain on the hard drive until you log off or they expire. On the other hand, session cookies are temporary and erased when you close your browser

This field is mandatory and fundamental.

Enable Authentication Logging

Enables logs for every authentication event. For example, every login, or log out. These logs can be seen from the Work Portal, in the Authentication log of the admin menu.

This field is not mandatory.

Federation Metadata Location

Specify the URL of the federation metadata XML document that complies to WS-Federation 1.2.

The URL has to use the HTTPS protocol (over HTTP), or reference the metadata file from a physical path.



This field is mandatory and fundamental.

Make sure that the Bizagi server has access to the metadata file as specified.

Idle sessions time-out


Determines the number of minutes for a session to get expired.

This field is mandatory and fundamental. Defined based on your authentication policies

Realm URI

Specify the URI of the wtrealm parameter, set as the entry point for Bizagi Work portal (when redirected).

The URI must use the HTTPS protocol.



This field is mandatory and fundamental.

Make sure that you use the same exact URL (case sensitive, and with the same format and slash characters) as defined at the ADFS; otherwise a trust relationship will not happen if there are differences.

Redirect to a logoff page after logoff process

By default Bizagi redirects to the login page. If you active this property, users are redirected to the logoff page configured in your WS-Federation.

This field is not mandatory.

Show detailed authentication error messages

If you activate this property, Bizagi will show the detailed error message on the login page.

Do not activate this in production environments. This option must be active only for troubleshooting authentication issues.


Checkpoints and recommendations

Once you set up both your Identity provider and Bizagi's Federated authentication parameters, and when running Bizagi Work portal in a .NET platform, you should make sure that there are no networking issues to access the ADFS server and its metadata (e.g, targetting https://[your_ADFS_server].[your_domain].loc/FederationMetadata/2007-06/FederationMetadata.xml from a browser in Bizagi's server should show results).



Even though for a successful setup and the trust relationship between Bizagi and the ADFS, there should be and allowed connectivity between these two services, at runtime having end user devices connect to both services can also cover such requirement.


You may also use the following test page as a checkpoint:



If this page loads up the claims and a successful authentication status (as shown below), you will verify that your configuration is OK.




In case that you need to troubleshoot your configuration in a development environment, you may edit the following key at the web.config file of your Work portal (by default at C:\Bizagi\Projects\[your_project]\WebApplication\) in order to analyze error traces:

<add key="ShowDetailedAuthenticationMessage" value="true" />



Note that the configuration for federated authentication in execution, will be stored into a XML located by default as C:\Bizagi\Projects\[your_project]\WebApplication\FederationAuth.config.

You may also verify that the above parameters are set in this file.




When configuring authentication against an ADFS, make sure the following:

1. The IIS' application pool as employed by the Work portal, explicitly defines the use of a service account, along with having the Load User Profile setting in true.




2. The Work portal's root folder (i.e., where the web.config is contained) allows both read and write access to the service account used by the IIS' application pool.

According to the sample image above, this should correspond to having Network service granted with write access: