Alternative manual configuration with Azure AD

Overview

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

This section is a step-by-step guide about the configuration needed, both in Azure AD and in Bizagi, to have integrated authentication in Bizagi through Azure AD.

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.

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.

2. Configure your IdP in Bizagi

After you configure the application in Azure AD, now you must access the Bizagi Studio or the Management Console and register the Identity Provider. Follow the steps in Configure a SAML 2.0 IdP in Bizagi.

3. Download the Bizagi metadata file

After you configure the identity provider in Bizagi, you must generate the metadata file. Refer to Download the metadata file.

4. Configure Bizagi as Service Provider in Azure AD

Do this in the admin options provided by Azure AD.

4.1 Access your Azure subscription with the Azure AD service using any of the following roles: Global Administrator, Cloud Application Administrator, Application Administrator, or owner of the service principal.

You will need to sign in to Azure's portal at https://portal.azure.com.

4.2. Go into your Active Directory.

Click the Active Directory option at the left panel and select App registrations. Click New registration.

4.3. Input the app's basic details

Provide your app´s name and select a Supported account Type (Single tenant Recommended).

For its Redirect URI input the base URL where your end users access the Bizagi Work Portal. The Web option must be selected

Consider:

•For Automation Service (cloud projects), this URL is:

https://[project_environment]-[your_project]-[your_company].bizagi.com

Replace [your_company], [your_project] and [project-name] with your subscription's values accordingly.

Similarly, replace [project_environment] with test for a Testing environment, or with nothing at all for a Production environment.

•For on-premises projects, Bizagi projects, the URL is:

https://[your_server]/[your_project]

Replace [your_server] and [your_project] depending on how you set up your environment.

Click Register when you are ready.

4.4. Set the Application ID URI in the newly created app. The URL configured in this parameter must be an EXACT match to the one registered in the Service Provider URL property of Bizagi Studio or the Management Console, this property, in both Bizagi and Azure, is case sensitive and it is how Bizagi and Azure link, in other words, it is an identifier between the two systems.

To do this, go into the Add an Application ID URI option of the newly added app.

4.5. Click Set next to Application ID URI and configure the App ID URI to reference the Bizagi Work Portal.

For Automation Service, such URL uses this format:

https://[environment]-[project]-[company].bizagi.com

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

https://[server]/[project]

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

The requested URL may be different according to the architecture you have. For example, in a cluster environment, you need to set the URL of the balancer or proxy server, which is the same URL used to access the Work Portal.

Click Save when you are ready.

4.6. Go to Authentication option and add a redirect URI so that it references the Bizagi Work Portal with the /saml2/assertionConsumer suffix. The Web option must be selected.

For Automation Service, such URL uses this format:

https://[environment]-[project]-[company].bizagi.com/saml2/assertionConsumer

Consider alternatively, if you cloud project uses this format instead:

https://[environment]-[project]-[company].bizagi.com/[project]/saml2/assertionConsumer

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

https://[server]/[project]/saml2/assertionConsumer

4.7. Locate the Logout URL and enter the Bizagi Work Portal URL while adding the /saml2/logout suffix.

Click Save when done.

4.8. Look up your endpoints

Go to Overview and look up the Endpoints to find the URL of the metadata location that you will need later on for configuration in Bizagi.

At this point, configuration directly in Azure AD is set. Now go to Bizagi to complete the procedure.

Once you have this file's URL, go back to Bizagi and set it in this key:

Now when you run the Work Portal, Bizagi displays the IdP's log-in page and users can be authenticated with your IdP.

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, are not reflected immediately unless you explicitly refresh the cache of the application server.

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