SAML authentication

<< Click to Display Table of Contents >>

Navigation:  Identity and access management >

SAML authentication

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, including SAML 2.0.

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

 

This section gives a high-level explanation of how integrating an Identity Manager works, when relying on the SAML 2.0 protocol.

 

It is strongly recommended that you integrate your corporate Identity Manager with Bizagi (to use a Federated authentication).

In case that you do not wish to integrate your Identity Manager, you may always rely on Bizagi's local authentication.

Though Bizagi's local authentication offers secure sign-in features (i.e, HTTPS and encryption of passwords at rest) along with configuration parameters which allow you to enforce your password/accounts policies (e.g, setting maximum number of login attempts, minimum password lengths, session timeout, etc), there are a series of outstanding benefits when integrating your Identity Manager.

Such benefits are:

 

1. Presenting a single and unified login screen to your end users.

When integrating your Identity Manager, Bizagi will delegate the authentication to it, and this implies that end users will be directed to the login screen as provided by that Identity manager.

In terms of usability perceived by your end users, this avoids you to have to present multiple different login screens (of different applications that these users work with).

Similarly, end users will only need to remember a unique login account and its password (avoiding to have to manage multiple login accounts and corresponding passwords).  

 

2. Centralizing your users repository and its authentication system.

Integrating your Identity Manager reduces the administration overhead that is produced when you have multiple authentication systems, due to those tasks that come to be needed periodically (such as handling idle accounts, resetting passwords, etc).

When integrating your Identity Manager, passwords are not stored in Bizagi and Identity and Access Management is done entirely by you at your Identity Manager.

 

3. Enforcing security policies.

By relying on your Identity manager, you may enhance security measures in it at the same time you enforce strict security policies (e.g, such as password policies, account characteristics and profiles, etc).

For instance, you may rely on multi-factor authentication as supported by your Identity manager.

 

4. Providing a best user experience for end users.

End users accessing Bizagi from any location or device (desktop, tablets or mobiles), will rely on standard protocols.

Regardless of the authentication type, Bizagi supports secure protocols such as HTTPS for all communications.

For all options that integrate an Identity manager, except for a point-to-point LDAP integration, the use of web-based protocols is employed (e.g, SAML 2.0). Such protocols enable a Single Sign-On experience.

 

 

Connecting your SAML-compliant Identity Manager

This image illustrates how you can integrate your Identity Manager with Bizagi so that your Identity Manager handles authentication.

 

Federated Authentication_SAML

 

Note:

Your Identity Provider (or Identity Assertion Provider), is responsible for providing 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.

When you use an integrated Identity Provider, Bizagi does not store passwords and the system architecture relies on HTTPS for the communication.

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

 

Regarding HTTPS:

Your Identity Provider have 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 Automation Service. However, for on-premises projects, you 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

You also need certificates to sign off messages that are exchanged (assertions). Encrypting the messages is optional, and also depends on whether your Identity Provider supports it.

You can use the same server certificates (if it is in P12 format) for all purposes, though it is a best practice to use separate certificates for each server.

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

If you use a self-signed certificate and want detailed steps for this, consult the Issuing and installing certificates article.

Similarly, you may reuse a certificate you already have (e.g, one of your local machine).

 

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.        

 

Bizagi requires that assertions are always signed off (both for sending and receiving), though encrypting those assertions is optional.

Supported algorithms for the messages are: SHA1 and SHA256.

 

note_pin

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

 

How to configure SAML-based authentication

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

The integration uses a certificate for signing assertions. you can use an additional certificate to encrypt assertions if supported by your Identity Provider.

This step is not bound to Bizagi nor restricted by any special requirement of Bizagi (you carry it out yourself).

 

Apart from this, here is an outline of what needs to be done, both by the Identity Provider and at Bizagi:

 

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

Within these settings, you configure:

Enable assertion encryption: Set this option to On by checking the checkbox to encrypt assertions generated by Bizagi.

Enable authentication logging in database: Set this option to On to have the web application log every authentication event. You can view the log from the Work portal.

Encryption certificate: Use the Browse button to locate and upload the digital certificate (in P12 format, containing the public and private keys) 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, we recommend different certificates, especially on production environments.

Using self-signed certificates is supported.

A P12 format is equivalent to PFX format (if you have a PFX simply rename that file changing its extension).

Encryption certificate password: Type the password for the digital certificate for encryption.

Applicable when enabling the Enable assertion encryption property.

Force authentication: Set this option to On to avoid SSO capabilities and request credentials every time users attempt to log in at Bizagi.

Identity Provider Metadata File Path: Provide the path, usually a URL, to where the metadata file of the Identity Provider is located. For on-premises Bizagi projects, you can also use a full disk path while ensuring adequate access rights.

Idle session time-out: Define the number of minutes of inactivity after which a session expires.

Organization name: Provide the name of your organization. The name is included within the request messages sent by Bizagi.

Organization URL: Provide URL of the website of your organization. The URL 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.

Selecting REDIRECT may not be optimal when encrypting assertions, as such messages become part of the URL. The URL may get long enough to trigger 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.

Selecting REDIRECT may not be as optimal when encrypting assertions, as such messages become part of the URL. The URL may get long enough to trigger 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 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 URL is case-sensitive. For Automation Service, leave [environment]- blank for the production environment.

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

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

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

Using self-signed certificates is supported.

A P12 format is equivalent to PFX format (if you have a PFX simply rename that file changing its extension).

Technical email contact address: Provide an email address for contacting your corporation, regarding technical issues. The email is included within the request messages sent by Bizagi.

 

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.

 

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

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

For most Identity Providers, you specify/confirm Bizagi's URL, and load information from a metadata file.

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

The exact steps to accomplish this may vary for different Identity Providers, however, some general concepts apply in all cases.

 

View examples and guided steps for the different Identity Providers through the links 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 the Bizagi Work portal automatically see the login screen of your Identity manager.

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

 

Integrated authentication possibilities

Through SAML 2.0 support, Bizagi supports the following authentication systems:

 

IDENTITY

MANAGER

CHARACTERISTICS AND SUPPORT

TECHNICAL SPECS

(PROTOCOLS AND STANDARDS)

Azure AD

Azure AD service is supported as provided by Azure's cloud services (from a subscription provided by the customer).

Supports a Single Sign-On (and Single Logout) experience for active browser sessions (not at a network-level).

There are two options to connect with Azure AD:

1. Through SAML 2.0.

2. Through the OAuth 2.0 protocol and its OpenID extension.

 

For more information about this alternative, refer to Authentication with Azure AD.

Microsoft

Active Directory Federation Services

(ADFS)

Microsoft ADFS support is officially certified with version 3.0.

Supports a Single Sign-On experience (and Single Logout) for active browser sessions (not at a network-level).

There are two options to connect with ADFS, though the first one is strongly recommended:

1. Through SAML 2.0.

2. Through the WS-Federation protocol (involves WS-Trust). The WS-Federation protocol uses assertions based on the SAML token spec, version 1.1, though these are not entirely SAML-compliant.

 

For more information about this alternative, refer to Authentication with ADFS.

NetIQ

NetIQ officially certified with version 4.4.

Supports a Single Sign-On experience (and Single Logout) for active browser sessions (not at a network-level).

Relies on SAML 2.0.

 

For more information about this alternative, refer to Authentication with NetIQ.

Okta

Supports a Single Sign-On experience (and Single Logout) for active browser sessions (not at a network-level).

Relies on SAML 2.0.

 

For more information about this alternative, refer to Authentication with Okta.

PingFederate

PingFederate is officially certified with version 8.4.3.

Supports a Single Sign-On experience (and Single Logout) for active browser sessions (not at a network-level).

Relies on SAML 2.0.

 

For more information about this alternative, refer to Authentication with PingFederate.

SiteMinder

SiteMinder is officially supported.

Relies on SAML 2.0.

 

note_pin

Identity Managers not explicitly listed above, are not officially supported or certified.

This means that while you may want to use a different SAML-compliant Identity Manager, it is advisable to first check with our support team.

For high-level information about how authentication works when using a SAML-compliant Identity Manager, refer to Authentication via SAML.