SAML configuration with ADFS

<< Click to Display Table of Contents >>

Navigation:  Environments identity and access management > Work Portal access > SAML authentication >

SAML configuration with ADFS


Bizagi supports integration with Identity and Access Management systems (i.e, Identity Managers or Identity Providers) which are SAML 2.0 compliant, such as Microsoft ADFS.

This section is a step-by-step guide to configuring in ADFS and in Bizagi to have an integrated authentication in Bizagi against ADFS.




For SAML 2.0, both your Identity Provider and your Bizagi project must be set up to support HTTPS.

For introductory information about SAML 2.0, refer to Authentication via SAML.



To configure ADFS, as with any Identity Provider supporting SAML 2.0, you need:


1. To have previously generated and imported your own certificates

The integration uses the for signing assertions.

This step is not bound to Bizagi nor restricted by any special requirement of Bizagi (you usually do it yourself).

If you need some guidance or an example on this step, refer to Generating and installing certificates.


To proceed with the guided steps below, you need to have already imported certificates in your Identity Provider. You need the following information:

The certificate information (.p12 file).

The password for that .p12 file, as defined by you at the moment of exporting the public and private key.


If you will be encrypting assertions as well, you also need this information for another certificate.



To continue, you need to be in charge of managing your installed certificates (keeping track of expiration dates and any other relevant maintenance aspects such as handling changes in your Identity Provider's endpoints).


2. To have already imported and synchronized your users into Bizagi

When integrating any Identity Manager, you need to synchronize the accounts that are authorized to access Bizagi's Work portal.

Synchronizing means importing or updating the account's primary identifier only (domain plus username typically, and the email address).

Bizagi does not store passwords when it is integrated with an Identity Manager. See User Synchronization.


Once you have verified in the Work Portal that there has been at least an initial import of your users into Bizagi, you may proceed



In Bizagi, unique identifiers for users are either: email, or the combination of domain and username.

The examples of SAML-based authentication provided below use email as the unique identifier for users.


3. An installed and fully configured and supported version of ADFS.

Bizagi supports ADFS version 3.0.

If you want to use a different version which supports SAML 2.0, check with our support team before proceeding.


What you need to do

1. Configure in Bizagi, the settings that make reference to your SAML setup.

2. Configure Bizagi as Service Provider in ADFS.



1. Configure in Bizagi, the settings that make reference to your SAML setup.

Use the Bizagi Management Console targeting the environment you want this configuration to apply to (e.g, development, testing, staging, or Production environmnt).

Alternatively and only for the Development environment, you may use Bizagi Studio.


1.1. If you are going to configure it from the development environment, open Bizagi Studio.


1.2. Locate the Security module. Click on the Authentication option found under the Security item.

Select Federated authentication from the drop-down list in the panel to the right, and SAML v2.0 from the drop-down at the lower right:




Click Update.

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



If you applied this change into an environment other than development, make sure to apply the same changes in your Development environment.

Follow the above procedure in the Bizagi Management Console.


1.3. Configure the additional parameters, making sure you click Update for each that you modify.

The parameter values are case-sensitive so you must be sure to input them correctly.


Fill in or configure these settings as described:

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 assertion encryption: When Bizagi sends messages to the Idp, it sends two types of assertions.

 -Authentication request: which does not have any sensitive information, therefore is not encrypted by standard definitions.

 -Session log out request: This assertion contains sensitive information, and can be encrypted. If you set this property on, session log out reques tare  encrypted by Bizagi. Make sure that your identity provider supports receiving log out request encrypted.

On the other hand, Bizagi can handle any encrypted message sent by the IdP, even if this property is set off.

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.

Encryption certificate: Use the Browse button to locate and upload the digital certificate (in P12 format, containing the public and private key) that will be used to encrypt the assertions generated by Bizagi.

Encryption certificate password: Provide the password of the digital certificate used for the encryption of assertions.

This password should match the one you defined when you exported certificate information in P12 format.

Force authentication: Check this checkbox (set to On) to disable SSO capabilities so that every time users attempt to log in to Bizagi, they have to provide their credentials. Using this option depends on your authentication requirements and expectations.

Identity Provider Metadata File Path: Provide the path to the ADFS metadata file. This location is typically a URL, such as the default https://[my_federateserver]/FederationMetadata/2007-06/FederationMetadata.xml

Provide the appropriate value for [my_federateserver].

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).

Organization name: Provide the name of your organization. This is included within the request messages sent by Bizagi.

Organization URL: Provide the URL of the website of your organization.This is included within the request messages sent by Bizagi.

Redirect to a logoff page after loggoff process: Check this checkbox if you wish to redirect users to a static logout page when they logout.

SAML Protocol Binding for SLO: We recommend selecting REDIRECT as supported specifically by Azure.

SAML Protocol Binding for SSO: We recommend selecting POST so that there is support for longer messages.

Service provider URL: Provide the full URL for the Bizagi Work portal.

For Automation Service, such URL uses this format:


For on-premises projects, the URL uses this format:


The above URL is case-sensitive. Do not enter anything for [environment]- to reference the Production environment.

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

Signature certificate password: Provide the password of the digital certificate used for the signing of assertions.

This password should match the one you defined when exporting certificate information in P12 format.

Signing algorithm: Select either SHA1 or SHA256.

Signing certificate: Use the Browse button to locate and upload the digital certificate (in P12 format), containing the public and private key that will be used to sign the assertions generated by Bizagi.

Technical email contact address: Provide an email address for contact with your corporation regarding technical issues.




When you are done, confirm that your changes have been applied.



Authentication changes may not be reflected immediately; you may need to reset the Bizagi services.


1.4. Perform a reset on your Bizagi services.

For on-premises projects, this means executing an IISReset.

Any change in the authentication type, or any of its settings, is not reflected immediately unless the cache of the application server is explicitly refreshed.


1.5. Browse for the location of a metadata file that Bizagi generates based on the previous configuration.

To configure ADFS throughout the next steps more easy, download the metadata file from Bizagi to a local path so you can input it into ADFS.


You may first review the metadata file by browsing it as:




Download the file by inputting in your browser:



2. Configure Bizagi as Service Provider in ADFS

Do this in the admin options in ADFS.


2.1. In your ADFS server, open the administration console.


2.2. Launch the creation of a relying party trust.

Right-click Relying party trust to display the options menu, and select the configuration wizard:




Click Start.




2.3. Select the data source.

To configure the relying party, select the Import data about the relying party from a file option and browse for the metadata file generated by Bizagi.




2.4. Select the metadata file.

Make sure you locate Bizagi's metadata.xml file.




Click Next when done.


2.5. Enter a unique name.

Give a display name to this configuration, for your convenience.




Click Next when done.


2.6. Skip multi-factor authentication.

Select the I do not want to configure multi-factor authentication settings for this relying party trust at this time option and click Next.




2.7. Choose issuance authorization.

Select the Permit all users to access this relying party option and click Next.




You see a summary of the information to set for this relying party trust, including the information that came from Bizagi's metadata file.

You may click Next when done.

You may also check (in the Advanced view) that the algorithm set for this use (either SHA1 or SHA256), matches the one configured in Bizagi.


2.8. Open the Claim rules editor.

Before you close the actual configuration window, check the Open the Edit Claim Rules dialog for this relying party trust when the wizard closes checkbox.




Then click Close.


2.9. Define a new claim rule by clicking Add Rule.





2.10. Select the Send Claim Using a Custom Rule template.




Click Next when done.


2.11 Create the following rules:


Rule 1


Rule name: email

Custom rule: c:[Type == "", Issuer == "AD AUTHORITY"] => issue(store = "Active Directory", types = (""), query = ";mail;{0}", param = c.Value);




Rule 2


Rule name: nameid

Custom rule: c:[Type == ""] => issue(Type = "", Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer, Value = c.Value, ValueType = c.ValueType, Properties[""] = "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress");




When you are done, your newly created rules are displayed as shown in the image below.




The rule may not be recognized right away. If so, delete the rule, create it once again and restart the ADFS server.


At this point you have configured your ADFS to rely on SAML 2.0 for an integrated authentication with Bizagi!

You will need to carry out the next part only if you have employed self-signed certificates.


Additional step for self-signed certificates

If you have issued and installed a self-signed certificate for your ADFS for signing and encrypting purposes, you will need to perform the following:

1.Access your ADFS server and open a PowerShell console.

2.Enter the following command:

Get-AdfsRelyingPartyTrust -Identifier [relying_party_trust] | Set-AdfsRelyingPartyTrust

-SigningCertificateRevocationCheck None -EncryptionCertificateRevocationCheck None

Replace [relying_party_trust] accordingly to the unique name given at the configuration above (when you register Bizagi's relying party trust).