Identity and access management

<< Click to Display Table of Contents >>

Navigation:  » No topics above this level«

Identity and access management


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

Supported protocols and standards are: SAML 2.0 (recommended), OAuth plus the OpenID Connect extension, and the LDAP protocol.

Authentication in Bizagi provides secure sign-in capabilities, compliance to your security and authentication policies, and autonomy regarding the management of user accounts, by any of two possibilities: By using local Bizagi authentication, or by integrating your corporate Identity Manager.


Connecting with your Identity manager

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

Outstanding benefits when integrating your Identity Manager 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 disabled 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 and 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).

And SAML 2.0 as a protocol, enables a Single Sign-On experience.




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

Though Bizagi's local authentication, you may also rely on secure sign-in features (i.e, HTTPS and encryption of passwords at rest), along with configuration parameters that allow you to enforce your password/accounts policies (e.g, setting maximum number of login attempts, minimum password lengths, session timeout, etc).


Integrated authentication possibilities

Through SAML 2.0, Bizagi PaaS supports Single Sign-On (and Single Log out) at a browser level, for the following authentication systems:







Azure AD

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


There are two options to connect with Azure AD:

1. Through SAML 2.0 (recommended).

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


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


Active Directory Federation Services


Microsoft ADFS support is officially certified with version 3.0.


There are two options to connect with ADFS:

1. Through SAML 2.0 (recommended).

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 the recommended alternative, refer to Authentication with ADFS.


NetIQ officially certified with version 4.4.


Relies on SAML 2.0.


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


Okta is supported as provided as a cloud service used by the customer.


Relies on SAML 2.0.


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


PingFederate is officially certified with version 8.4.3.

Relies on SAML 2.0.


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



Therefore, before you move on towards any configuration steps, ensure first that your Identity Manager complies to SAML 2.0.

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


Other possibilities

Other possibilities to setup your Bizagi authentication are:


LDAP: This type supports integration with an on-premises Microsoft AD and it relies on standard LDAP protocol (e.g, connecting via an LDAP URL with filters as supported by LDAP format).

For Bizagi PaaS, it requires VPN setup. It supports a "Same Sign-On" concept, while it doesn’t support a Single Sign-On experience (i.e, explicitly login is needed, though a unique and central account + password combination is employed).

For more information about this alternative, refer to LDAP authentication.


Bizagi: This type uses Bizagi’s local authentication mechanism, while allowing you to enforce your security policies for passwords and accounts.

For more information about this alternative, refer to Bizagi authentication.


OAuth: This type offers a Single Sign-on experience, while relying on the OAuth and OpenID Connect protocol for your Bizagi project to delegate authentication to an identity provider such as another Bizagi project.


The following image illustrates integrated authentication possibilities, while showing the possibility to directly target an LDAP server (as described in the next section):




Please bear in mind the following:

1.It is the customer's responsibility to manage end user accounts and their access to Bizagi’s Work portal.

This means that the customer is responsible as well for enforcing adequate security policies for these accounts and their passwords.

2.With any type of authentication, the default domain\admon system user should be kept as enabled, though this user should not be assigned to a specific end user, and it should not be granted with rights to use Work portal menus and options.

Instead, it is recommended to define an explicitly assigned user for your business administrator, having the privileges to use admin menu options (i.e modify parameter entity values, manage your users, licenses, cases, etc).

3.When integrating an Identity Manager, and regardless of the chosen one, customers need to synchronize the accounts that are authorized to access Bizagi's Work portal.

Synchronizing means inserting or updating the account's primary identifier only (domain plus username typically, and the e-mail) in Bizagi.

Recall that passwords are not stored in Bizagi when integrating an Identity Manager.



Synchronizing users is a task which should be carried out periodically and which may be carried out throughout any of these approaches:

1. Having a Bizagi process which expects an Excel file to be uploaded.

Such Bizagi process you will need to define; and such Excel file you will need to generate from the users information as managed by your Identity Provider.

2. Having a SOAP web services client on your side (at the customer's premises), which invokes Bizagi SOAP API in order to push information of users.

3. Having secure web services on your side (for the customer's Identity provider), so that these web services are invoked from a Bizagi process that pulls information of users.

Such Bizagi process you will need to define.

4. Having Bizagi connect to your Active Directory through an out-of-the-box feature which is set to run on a daily basis.

Recall that in order for Bizagi PaaS to access an on-premises system which does not offer a public endpoint, such as an Active Directory, you will need to use a VPN.


For testing purposes, you may simply import or register a couple of users manually in Bizagi, through its Work portal admin options.