<< Click to Display Table of Contents >> Navigation:  Environments identity and access management > Work Portal access

Overview

The Work Portal is a web application which lets each of your users perform their corresponding tasks and configurations. And as such, before working in the application, each user must identify himself to the system so that only the expected people can perform such activities.

This concept of identifying a user to a system is known as Authentication. This section covers everything you need to know about Authentication and whatever you need to do to configure it according to your needs in Bizagi.

 

Authentication explained

Simply put, authentication is the process of confirming the identity of a user against a system. In other words, it determines whether someone or something is in fact who or what it claims itself to be.

This concept has its own meaning and utility in technology, where it provides access control for systems by checking if the credentials provided by a user match those stored beforehand in the database of authorized users (which can be handled in a variety of ways, as it is described in this section). The following image illustrates how a user requests resources from the Work Portal but he needs to be authenticated to be granted access to such resources.

 

 

Authentication is commonly confused with Authorization, and even though the concepts are related, they are rather different. Authentication is in charge of letting in or denying the access of a user to a system, while Authorization is responsible of letting a user do only whatever he is supposed to. For example, if assistants are allowed to review some information but not edit it, the Authorization module of the application is the one that handles such functionality.

 

Authentication alternatives for the Bizagi Work Portal

There are plenty of ways of implementing the Authentication system of the Work Portal, they are described here from a general stand point but in this sub-hierarchy of the User's Guide you can find additional information on each one of them.

 

The diagram below depicts the authentication alternatives for a Bizagi application hosted on Automation Service, it shows the type of user experience they offer and whether the method is recommended.

 

 

•Federated authentication

This type of authentication delegates the responsibility of identifying and authenticating a user to a third-party configured server, as shown in the image below.

 

 

There are multiple types of Federated authentication, from those options Bizagi supports:

oSAML 2.0: With this type of authentication Bizagi delegates the authentication procedure to the third-party Identity Manager of your choice (Bizagi Supports integration with Azure AD, ADFS, NetIQ, Okta, PingFederate and SiteMinder) which will handle the information with secure messages through the SAML standard protocol. We encourage you to use this type of authentication since it is a widely adopted industry protocol that can be configured with multiple vendors. For more information about this method, refer to SAML authentication.

 

 

•OAuth: This type of authentication uses the OAuth and OpenID Connect protocols for your Bizagi project to delegate authentication to an identity provider such as another Bizagi project. The following image shows how you can setup this alternative using a VPN. For more information about this alternative, refer to OAuth authentication.

 

•LDAP Authentication: This type of authentication 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 offers a "Same Sign-On" user experience. For more information about this alternative, refer to LDAP authentication.

 

•Bizagi authentication: This type of authentication 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.

 

Authentication user experience alternatives

There are two notable user experiences when talking about authentication. Each one of them have different characteristics and are a consequence of the nature of the authentication alternative that has been configured.

 

Single sign-on is the concept of authenticating yourself once and get access to all of the the applications that share the same authentication method and third-party server.

 

 

Same sign-on refers to using the same user credentials in each of the log in screens of the applications a user needs have access to.

 

 

Authentication protocols summary

The following table describes the most important characteristics of each authentication protocol, from the perspective of what you can do with it from Bizagi.

 

 

Important

Keep in mind the following:

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

The customer is also responsible 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 enabled, though this user should not be assigned to a specific end user, and it should not be granted rights to use Work Portal menus and options.

Instead, we recommend that you define a user explicitly assigned as your business administrator, with 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, you 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 email) in Bizagi.

Remember that passwords are not stored in Bizagi when you integrate an Identity Manager with it.