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, the your Identity Provider must be set up to support HTTPS.
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.
1.3 An installed and fully configured and supported version of ADFS.
Bizagi supports ADFS version 3.0 or 4.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
An outline describing the configuration needed to sign in with your identity provider considers these steps:
Follow the steps presented to integrate your SAML 2.0 IdP after you've created the company users:
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.
Provide the path where the IdP metadata file is located. This location is typically an URL.
This property is not mandatory and can be provided later at the end of the configuration procedure.
You can also paste the XML or upload an XML file.
•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.
When Bizagi sends messages to the identity provider, it sends two types of assertions.
•Authentication request: This 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. Consult your identity provider the SSO supported bindings.
•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 using the Email address.
Sign Off options
•Binding SLO: This indicates if the log out requests must be using the POST or REDIRECT (GET) HTTP method. Consult your identity provider the SSO supported bindings.
•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 is encrypted by Bizagi using the encryption certificate. Make sure that your identity provider supports receiving log out request encrypted.
•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.
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:
Do this in the admin options in ADFS.
3.1. In your ADFS server, open the administration console.
3.2. Launch the creation of a relying party trust.
Right-click Relying party trust to display the options menu, and select the configuration wizard:
Select Claims aware and Click Start.
3.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.
Click Next when done.
3.4. Enter a unique name.
Give a display name to this configuration, for your convenience.
Click Next when done.
3.5 Configure the Issuance Authorization rules by choosing the Permit all users to access this relying party option.
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.
3.6 Create the Claim rules for this trust by selecting the Configure claims issuance policy for this application.
This way, upon trust creation you immediately create a claim rule and finish the configuration.
Then click Close.
3.7. Right click the Party Trust created and click Edit Claim Issuance Policy.
Define a new claim rule by clicking Add Rule.
Make sure you can send UPN, Email address and Name as information within the claim that is passed into the Customer Portal.
For instance, you can create a new claim rule by choosing the Send LDAP Attributes as Claims template:
Configure the rule by giving it a name, and explicitly including:
•Attribute store: Attribute Directory.
•Mapping of LDAP attributes to outgoing claim types, including:
oUser-Principal-Name mapped to the UPN
oEmail-Addresses mapped to the E-mail Address.
Bizagi considers the following priority in the assertions:
Both UPN and Email Address must be in email format: [name]@[provider].[domain]. For example firstname.lastname@example.org.
For the UPN claim type make sure that the email is defined as the user name.
You should have a registered claim rule for your specific relying party configuration.
Once you have verified this is correct, click OK.
Set the Secure Hash Algorithm in ADFS 3
If you are using ADFS 3 make sure that the Secure Hash Algorithm is SHA-256. To change that, right-click the client created previously and select properties. Click the Advanced tab and select SHA-256 as the Secure Hash Algorithm.
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: