Azure AD B2C is an Identity Access Management system that enables users to use social, enterprise or personal accounts to get SSO access to the application where is configured.
This article provides a step-by-step guide about the configuration needed, both in Azure AD and in Bizagi, to integrate your authentication in Bizagi through Azure AD B2C. Note that these steps are done only once, typically by an admin user of your Customer Portal having access to your Azure AD B2C.
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 B2C supporting SAML 2.0, you need:
•Have a resource with an Active Directory B2C.
•Create a B2C Tenant inside the Azure AD B2C. To know how to create a B2C Tenant, click here.
Associate the SAML 2.0 protocol with the B2C.
Configure the necessary policies to support SAML 2.0
To do so, go to your tenant configuration and go into the Identity Experience Framework.
Bear in mind that you need to be in the subscription and in the active directory where the B2C tenant was created.
Create the Policy Keys needed to establish trust with the services that you are going to integrate with. For this, click Policy Keys and then click Add.
Register a SAML application in Azure AD B2C. For more information about registering a SAML application in your Azure AD B2C, click here.
To know more about custom policy keys, click here.
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.
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).
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.
In Bizagi, unique identifiers for users are either email or the combination of domain and username. We recommend using the email as the Unique Identifier in Azure.
What you need to do
To configure Azure AD B2C in your project, follow these steps:
Open the Bizagi Studio project or the Management Console of your environment, and set the Authentication properties:
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 assertion encryption: 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.
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 check box (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 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.
This password should match the one you defined when you exported certificate information in P12 or PFX format.
•Force authentication: Check this check box (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 where the Azure AD metadata file is located. This location is typically an URL. Such URL in Azure AD is usually found at:
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 a fictional metadata. For example you can use the contoso Microsoft fictional's company for testing purposes:
Later you can reconfigure this parameter at the end of the configuration procedure. See Get the Azure metadata file.
•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 log-off page after log-off process: Check this check box if you wish to redirect users to a static log-out page when they log-out.
•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.
Notice that the values you provide for the settings are encrypted in Bizagi when you save them.
After this step is completed, Bizagi generates a metadata.xml file. You can use it as input in the next step.
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:
Download the file by inputting in your browser:
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 https://portal.azure.com.
Make sure that you need to be in the subscription and in the active directory where the B2C tenant was created.
3.2 Register the Application
Open the Azure AD, and select the App registrations menu. Click New registration:
Give a name to your application. Then, select the supported account types. Make sure that you select the tenant associated to the B2C. Finally, type your project's URL.
3.3 Change the application manifest
Once your application is registered, you will be able to see it in the App registrations menu. Go to the application.
In the manifest, change the following parameters with the values below:
Go to the Identity Experience Framework and open the TrustFrameWorkBase file.
Look for the TechnicalProfile node associated to the SAML protocol. Inside, copy the IssuerUri, which is the metadata URL associated to the SAML assertions generator.
Finally, add the following suffix to the URL copied: Samlp/metadata
The metadata URL must have the following format:
where <B2Ctenant> is the name of the B2C tenant created in the Azure AD B2C.
Open your Bizagi Studio Authentication configuration, or using your Management Console, and paste the URL:
Now when you run the Work Portal, Bizagi displays the Azure's log-in page and users can be authenticated with your Azure AD.
Remember to do this configuration in all your environments, or to deploy security configurations in your target environments, for example, test or production environments.