Configure Azure AD using SAML 2.0

<< Click to Display Table of Contents >>

Navigation:  Bizagi Studio Collaboration Services > Enterprise subscription > Accessing Portals and Applications > How to manage identity providers > SAML 2.0 Examples >

Configure Azure AD using SAML 2.0


To integrate your cloud portals with your corporate Azure AD you need to carry out the configuration steps as described in this section.

Note that these are done only once, typically by an admin user of your Customer Portal having access to your Azure AD.


Once you have carried out these steps users sign in to any cloud-based service directly via your Azure AD, as described at Signing in the Bizagi Cloud Portals and Applications.


Before You Start

To configure Azure AD supporting SAML 2.0, you need:


1.1 To have previously generated and imported your own certificates.

The integration uses the certificates to sign assertions.

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

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


To proceed with these guided steps, you need to have imported certificates into your Identity Provider. For this exercise, you need:

The certificate information in .P12 or .PFX  file format.

The password for the certificate file, as defined by you when you exported the public and private keys.


Azure AD particularly does not demand that the P12 certificates match configuration on Azure's side.


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


For further information about certificates refer to Considerations about certificates for SAML authentication.



You will need to be in charge of managing your installed certificates (keep track of its expiration date and other relevant maintenance aspects such as changes in your Identity Provider's endpoints).


1. 2. To have already users into the Customer Portal

When integrating any Identity Manager, you need to synchronize authorized accounts so they can access Bizagi 's cloud-based portals.

Synchronizing means importing or updating the account's primary identifiers. The Bizagi's account email must match with the attribute NameID of the SAML assertion. Usually the email is the most common parameter. See Create company users.


Bizagi does not store passwords when integrating an Identity Manager.



You cannot have two or more users with the same email, because it is considered as part of the primary identifier.


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


What you need to do

An outline describing the configuration needed to sign in with Azure AD considers these steps:

1.Configure your identity provider in the Customer Portal.

2.Download the Bizagi metadata file.

3.Register an authorized application in Azure AD.



Follow the steps presented to integrate your Azure AD after you've created the company users:


1. Configure your IdP in the Customer Portal

Access the Customer Portal as a company administrator, select the Settings Icon, open the Protocols menu, and click Add authenticator.




Select the SAML 2.0 option in the protocol drop-down list, and configure these settings:

IDP: Name of the identity provider associated with the protocol selected.

Display name: name of the authenticator displayed in the Customer Portal.

Description: Brief description of the authenticator.




Define the domains

If you need to activate multiple authenticators, you can define the email domains associated with each authenticator. See Multiple authenticators for cloud-based portals.


Metadata file

Provide the path where the Azure AD metadata file is located. This location is typically an URL. Such URL in Azure AD is usually found at:[tenant]/federationmetadata/2007-06/federationmetadata.xml


You need to provide the id of your tenant/subscription (as copied into your clipboard in the first steps of configuring Azure AD). Initially, you can use fictional metadata. For example, you can use the contoso Microsoft fictional's company for testing purposes.


Later, you can set the right metadata file. This property is not mandatory and can be provided later at the end of the configuration procedure. See Get the Azure metadata file.


You can also paste the XML or upload an XML file.




Signing Certificate

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

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.


Encryption Certificate


When Bizagi sends messages to the identity provider, 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 request are   encrypted by Bizagi. Make sure that your identity provider supports receiving log out request encrypted.


Verify that your Identity Provider supports the encryption of messages. If you do not know or encryption is not supported, leave these fields empty.


Encryption certificate: Use the Browse button to locate and upload the digital certificate (in P12 or PFX 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.




Sign In options

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

Force auth: set to Yes 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.

SAML Name ID Policy format: This is the format of the NameID (primary user identifier) expected by your identity provider. We recommend use the Email address.


Sign Off options

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

Encrypt messages: Bizagi sends a session logout request assertion. This assertion contains sensitive information, and can be encrypted. If you set this property Yes, session log out request are  encrypted by Bizagi using the encryption certificate. Make sure that your identity provider supports receiving log out request encrypted.




Company information

Organization Name: Name of your company sent in the assertion.

Organization URL: URL of your company sent in the assertion.

Technical Email Contact Address: Email address of your platform administrator.




2 Download the metadata file

Before configuring Bizagi as a service provider in your identity provider, you need to download a file that contains the metadata of the SAML configuration. This file is usually required by Identity Providers to define predefined configurations.


Make sure that you upload the Signing Certificate, and set the Signature certificate Password.

To download the metadata file, Bizagi has the following endpoints


You can review this metadata file by browsing it at:



You can either preview or download the file:




3. Configure the Enterprise Application in Azure AD

Do this in the admin options provided by Azure AD.


3.1 Log in to your Azure services with a user account with admin rights.

Access your Azure subscription with the Azure AD service.

You will need to sign into Azure's portal at




3.2 Register the Enterprise Application

Open the Azure AD, and select the Enterprise Applications menu. Click New Application:




Search the Bizagi application and select it:




3.3 Define users that are going to be authenticated in Bizagi using Azure SSO

Define users that are going to be authenticated in Bizagi, using Azure SSO. Add them manually or with any predefined group on your Azure AD. Remember that users must be registered in Bizagi.




3.4 Configure the Single sign-on properties

Select the Single sign-on menu, and click the SAML option:




3.4 Set up the metadata file

Now you can upload the metadata file downloaded in the step 2.




Review and fill the rest of mandatory fields:




Identifier (Entity ID):  It is the Bizagi 's URL of the authenticator module, it has this format, https://accounts-<companyname>

Reply URL: This is the destination in the SAML response: for example, https://accounts-<companyname>

Sign on URL: It is the Bizagi 's URL of the authenticator module, it has this format https://accounts-<companyname>

Logout URL: It is the Bizagi's authentication logut URL, for example https://accounts-<companyname>


3.5 Verify or upload the certificate

You must include the SAML signing certificate. If the configuration does not have a certificate, click Add a certificate and upload the same certificate used in the Bizagi's configuration.




If the certificate is configured correctly, you can see its properties. Make sure its status is active.




3.6 Define the Unique User Identifier

To identify users when they are being authenticated by Bizagi, you need to define the a Unique Identifier. In Bizagi, unique identifiers for users is the email. We recommend setting the email as the Unique Identifier. Click the edit icon in the User Attributes & Claims options:




Click the Unique Identifier:




Select the Email Address format, and user.mail as the Source Attribute:




3.7 Get the metadata URL

Finally, copy the App Federation metadata URL:






The metadata URL must have the following format:<TenantID>/federationmetadata/2007-06/federationmetadata.xml?appid=<applicationID>


It is very important to make sure that the appid parameter is contained at the end of the URL.


Access the Customer Portal as a Company Administrator, click the Settings icon, open the Protocols menu an edit the SAML 2.0 authenticator created previously. , Paste the metadata URL. Then save your changes.




Finally you need to activate the authenticator. Before activating the new authenticator, review carefully your configuration settings. Bizagi displays a warning message when activating the protocol.




To test your configuration we recommend that all users log out and opening a new tab using incognito mode, or use a different browser. If the configuration with a new IdP fails, you can Restore the authentication protocol.



In case the authenticator fails, you can review:

Troubleshooting SAML message exchanges

SAML Error codes