Configure a SAML 2.0 IdP in the Customer Portal

<< Click to Display Table of Contents >>

Navigation:  Automation Service Management > Accessing Portals and Applications > How to manage Identity Providers > SAML 2.0 examples >

Configure a SAML 2.0 IdP in the Customer Portal

Overview

To integrate your cloud portals with your corporate identity provider using SAML 2.0 you need to carry out the configuration steps as described in this section. Note that these are done only once, typically by a Company Administrator of your Bizagi Subscription. having access to your identity provider.

 

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

 

Before You Start

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

 

To have already registered 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.

Registering means providing 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.

 

note_pin

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 registering of your users into Bizagi, you may proceed.

 

Steps to configure your IdP in the Customer Portal

To configure an identity provider using the SAML 2.0 protocol, you must follow these steps:

 

1. Generate certificates to sign assertions (mandatory)

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 Certificates for SAML 2.0 authentication.

 

To proceed with these guided steps, you need to have:

One certificate to sign assertions (mandatory) in .P12 or .PFX  file format. You need The password for the certificate file, as defined by you when you exported the public and private keys.

One certificate to encrypt messages (optional) in .P12 or .PFX  file format. You need The password for the certificate file, as defined by you when you exported the public and private keys.

 

note_pin

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

 

2. Initial setup in your Identity Provider

First, you need to configure the Identity Provider. See some examples:

 

Azure AD

Azure AD B2C

ADFS

Okta

 

3. Add and setup the identity provider in the Customer Portal

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

 

customerportal_117

 

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.

 

customerportal_131

 

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 IdP metadata file is located. This location is typically an URL.

 

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

 

customerportal_132

 

Metadata URL depend on the IdP, here are some format examples:

 

Azure AD: https://login.microsoftonline.com/[tenant]/federationmetadata/2007-06/federationmetadata.xml

ADFS: https://[my_federateserver]/FederationMetadata/2007-06/FederationMetadata.xml

OKTA: https://[company].okta.com/app/[id]/sso/saml/metadata

 

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

note_pin

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.

 

customerportal_126

 

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.

oIf using Azure select REDIRECT.

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.

 

customerportal_127

 

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.

 

customerportal_128

 

4 Download the metadata file and upload it in your Identity Provider

Some identity providers need to upload the metadata file of the client. If your IdP requires uploading the metadata file, for example, in Azure AD, you need to download a file that contains the metadata of the SAML configuration done in the Bizagi's Customer Portal. This file is usually required by Identity Providers to define predefined configurations and includes the public key of the certificates for signing assertions and encrypting messages.

 

Make sure that you upload the Signing Certificate, and set the Signature certificate Password before downloading the metadata file.

 

To download the metadata file, Bizagi has the following endpoints:

 

https://accounts-[company].bizagi.com/saml2/metadata

 

You can either preview or download the file:

 

customerportal_129

 

Now you can upload the metadata file where is requested in your identity provider.

 

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.

 

Troubleshooting

In case the authenticator fails, you can review:

Troubleshooting SAML message exchanges

SAML Error codes