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.
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.
HTTPS support in Bizagi is setup automatically with Automation Service.
|
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.
|
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) |
|---|---|---|
Entra ID |
•Entra ID 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 Entra ID: 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 Entra ID. |
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. |
|
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/
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.
Last Updated 9/11/2024 9:16:02 AM