SAML authentication

<< Click to Display Table of Contents >>

Navigation:  Environments identity and access management > Work Portal access >

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

 

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

 

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.

 

FederatedAuthentication

 

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 specs

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.

 

View examples and guided steps for the different Identity Providers through the links below.

 

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 can be supported as long as they are SAML 2.0-compliant. In case of any issue contact our support team. See SAML general configuration.

 

Bizagi SAML 2.0 Endpoints

Bizagi exposes a set of endpoints regarding SAML authentication. This endpoints help you configure your authentication and are the ones responsible for the communications between Bizagi and your IdP. Endpoints precedes this URL.

For Automation Service, the URL has this format:

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

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

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

 

Those endpoints are:

/saml2/assertionConsumer

oThis endpoint processes SAML response assertions sent by the IdP.

/saml2/logout

oProcesses SAML logout requests sent by the IdP.

/saml2/metadata.xml

oDownloads the SAML metadata file for the project.

/saml2/metadata.xml?mode=preview

oShows in the browser the SAML metadata.