SAML authentication

<< Click to Display Table of Contents >>

Navigation:  Bizagi Studio > Security definition > Work Portal Security > Authentication >

SAML authentication

Available soon

 

Overview

Bizagi supports integration with Identity and Access Management systems (i.e, Identity Managers or Identity Providers) by means of secure industry protocols and standards.

Among such secure protocols, SAML 2.0 is supported.

SAML 2.0 is the most widely-adopted industry protocol employed for authentication, and renown Identity Managers in the market support it.

 

This section describes a high-level detail regarding how integrating an Identity Manager works, when relying on the SAML 2.0 protocol.

For introductory information about authentication options in Bizagi, refer to Identity and Access Management.

 

Connecting your SAML-compliant Identity Manager

The following image illustrates how you may integrate your Identity Manager with Bizagi, so that authentication is delegated to your Identity Manager.

 

Federated Authentication_SAML

 

Notice in the above scheme:

That your Identity Provider (or Identity Assertion Provider), is responsible of providing the authentication through standard SAML assertions (secure tokens).

Bizagi is set up as a Service provider, which entrusts the authentication to the Identity Provider by having a predefined trust relationship with it.

While using such an integrated Identity Provider, passwords are not stored in Bizagi and the system architecture relies on HTTPS for the communication.

A Service provider is defined as any Entity (as a system) which has those target services which end users want to access in the end. And the Identity Provider is defined as that trusted system which authenticates end users (supporting SSO) so that they can access the contents and services of Service providers.

 

Regarding HTTPS, consider:

Your Identity Provider must be set up having HTTPS support. For this, you need a valid and up-to-date certificate to install on your Identity Provider server.

HTTPS support in Bizagi is setup automatically with Bizagi PaaS. On the other hand and for <%ONPREMISES%> projects, you will need a similar valid and up-to-date certificate to install on your Bizagi server.

Certificates for this use are referred to as SSL/TLS server certificates.

Valid certificates (i.e for your production environment) need to correspond to those issued/recognized by a valid Certificate Authority (CA).

 

note_pin

In addition to the above, you will also need certificates to sign off messages that are exchanged (assertions). Encrypting the messages is optional, and it also depends on whether or not your Identity Provider supports it.

You could use the same server certificates for all purposes (must be in P12 format), though it is a best practice to use separate ones according to their use.

For the certificates which are employed to sign or encrypt messages, you may use self-signed certificates without implying any security concerns. Self-signed certificates are those which are not issued by a public Certificate Authority, and which you may locally generate no your own by means of SDK tools such as Java's keytool, OpenSSL or others.

In case that you will be using a self-signed certificate and want detailed steps for this, then you may follow the Issuing and installing certificates article.

 

Technical spec

Support for SAML 2.0 considers the following characteristics (from the SAML 2.0 spec):

Authentication Request Protocol.

HTTP Redirect Binding and HTTP POST Binding.

Web Browser SSO Profile, including:

oSP Redirect Request; IdP POST Response

oSP POST Request; IdP POST Response

oSingle Logout

Identity Provider Metadata - SSO Service Metadata.        

 

As previously mentioned, Bizagi will require that assertions are always signed off (both for sending and receiving), though encrypting those assertions is entirely optional (both for sending and receiving).

Supported algorithms for the messages are: SHA1 and SHA256.

 

note_pin

Note that SP stands for Service provider, while IdP stands for Identity Provider.

 

How to configure SAML-based authentication

In order to integrate your SAML-compliant Identity Provider with Bizagi, you will need to have previously generated and installed your own certificates.

Such certificates are employed in this integration for the purpose of signing assertions.

This step is not bound to Bizagi nor restricted by any special requirement of Bizagi (it is usually carried out on your own).

 

Parting from this, the following outline of steps describes what needs to be done, both at the Identity Provider and at Bizagi:

 

1. Configuring in Bizagi, the settings that make reference to the specification of your SAML setup.

Within these settings, you will configure:

Enable assertion encryption: Tick this checkbox (set to On) to encrypt assertions generated by Bizagi.

Enable authentication logging in database: Tick this checkbox (set to On) to define if the web application must log every authentication event (viewed from the Work portal).

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

Applicable when enabling the Enable assertion encryption property.

Even though it is possible to reuse the same certificate as employed for the Signing certificate setting, it is recommended to use different ones specially on production environments.

Using self-signed certificates is supported.

Encryption certificate password: Type the password for the digital certificate as used above for the encryption.

Applicable when enabling the Enable assertion encryption property.

Force authentication: Tick this checkbox (set to On) to avoid SSO capabilities so that every time users attempt login at Bizagi, credentials are explicitly requested.

Identity Provider Metadata File Path: Type the path where the metadata file of the Identity Provider is located. This location is typically an URL. For on-premises Bizagi projects, using a full disk path is also possible, while ensuring adequate access rights.

Idle sessions time-out: Define the minutes for which a session will expire.

Organization name: Type the name of your organization. Such information is included within the request messages sent by Bizagi.

Organization URL: Type the URL of the website of your organization. Such information is included within the request messages sent by Bizagi.

SAML Protocol Binding for SLO: Select either POST or REDIRECT to define which Binding implementation to use in single logout.

Consider that selecting REDIRECT may not be as optimal when encrypting assertions, given that such messages would be sent within the URL and these would become lengthier, potentially triggering errors in some browsers.  

SAML Protocol Binding for SSO: Select either POST or REDIRECT to define which Binding implementation to use in single Sign-on.

Consider that selecting REDIRECT may not be as optimal when encrypting assertions, given that such messages would be sent within the URL and these would become lengthier, potentially triggering errors in some browsers.  

Service provider URL: Type the full URL (including the project) of the Service Provider. This means entering the URL for Bizagi Work portal. For Bizagi PaaS, such URL uses this format:

https://[environment]-[project]-[company].bizagi.com/, while for on-premises projects, the URL uses this format:

https://[server]/[project]/.

Recall that the above URL is case-sensitive, and that for Bizagi PaaS, [environment]- should be disregarded (left as blank) while in a production environment.

Signature certificate password: Type the password of the digital certificate used for the signing of assertions.

Signing algorithm: Select either SHA1 or SHA256 to define which algorithm to use when signing assertions.

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

Using self-signed certificates is supported.

Technical email contact address: Provide an e-mail address for contact with your corporation, regarding technical issues. Such information is included within the request messages sent by Bizagi.

 

Notice that the inputted values for these settings above, will be encrypted in Bizagi when saved.

After this step is completed, a metadata.xml file is produced so that it serves as input for the next step.

 

2. Configuring Bizagi as Service Provider in your Identity Provider.

By going into your Identity Provider's admin options, you should be able to register Bizagi as a trusted Service Provider.

When registering Bizagi as a trusted Service Provider, you are usually expected to specify/confirm Bizagi's URL, and load information from a metadata file.

Along with this configuration, you will be defining the certificate to use to sign assertions, and defining which information is sent exactly within assertions (i.e, the user's unique identifier such as the email). Configuration regarding a certificate to use to encrypt assertions is optional and it depends on whether or not your Identity Provider supports it.

The exact steps to accomplish this may vary graphically from Identity Provider to Identity Provider, however, same concepts apply.

 

View an example and guided steps for the different Identity Providers as referenced below.

 

note_pin

Once your users are synchronized into Bizagi, and you have set SAML 2.0 authentication in both Bizagi and your Identity manager, end users accessing Bizagi Work portal will be automatically presented with the login screen of your Identity manager.

Whenever users are already logged in with a valid session, they will not need to input credentials.

 

Step-by-step guide

For further information about how to actually configure Bizagi to work with your SAML-compliant Identity Manager:

How to setup Authentication with Azure AD.

How to setup Authentication with ADFS.

How to setup Authentication with NetIQ.

How to setup Authentication with Okta.

How to setup Authentication with PingFederate.