Authentication

<< Click to Display Table of Contents >>

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

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, such as SAML 2.0 (recommended), the OAuth and OpenID Connect and 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.

 

Connecting with your Identity manager

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.

 

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.

 

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.

 

Other possibilities

Other possibilities to setup your Bizagi authentication are:

 

Windows: This type allows Bizagi to validate users against domains and Windows machines automatically.

This is done by having the Work Portal delegate the authentication to the windows machine on the client side (passwords will not be stored in Bizagi).

You may also have Bizagi take the Windows session credentials automatically and avoid a login page (achieve a SSO experience at a network level).

For more information about this alternative, refer to Windows 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.

 

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

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 account + password is employed).

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

 

Custom: This type enables the authentication to be handled by an external application.

With custom authentication, you develop your own component which overrides the methods by Bizagi in its Authentication component.

This way and by itself, the component you develop may rely on any APIs or other third-party components and connections to authenticate the user (i.e. validate against a MySQL database, XML files, a legacy system's database, etc).

For more information about this alternative, refer to Custom Authentication.

 

Mixed: This type allows you to use two different types of authentication in order to handle users from 2 different domains. One of the types must be Bizagi Authentication; and the other type may be either Windows or Custom Authentication.

For more information about this alternative, refer to Mixed Authentication.

 

Important

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. It is the customer's responsibility to ensure settings that enforce 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.

 

note_pin

Synchronizing users is a task which may be scheduled in Bizagi, by having it connect to your AD.

Alternate options to an AD/LDAP sync consider invoking Bizagi web services from your end (a "push"), or having Bizagi invoke a web service on your side to fetch users (a "pull").

If you will not synchronize users about yet, then you may test that the authentication works as expected by simply creating one user manually in Bizagi Work portal for validation purposes.

 

Configuration

The Security module in Bizagi includes an Authentication component that has great versatility in user management and validation.

You may choose the type of Authentication from a series of possibilities that can be used by your Work Portal, according to your company's needs.

Through this module, authentication may be set up with Bizagi Studio; or similarly through the Management Console for live environments (e.g, testing or production).

 

Authentication1

 

 

Authentication in runtime

Due to standard security measures, detail on error messages regarding failed authentication attempts are not displayed at the Work portal (to the end user).

In a production environment, you will need to have your system administrator review the event log details.

In a development environment, you may enable a temporary key to speed up your implementation and testing.