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 theirself 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 in order 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
|
If you plan on using an authentication method different than Bizagi and you are performing a deployment to an environment with no users on it (normally this would only be the case for a project's first deployment), follow these steps so that you can correctly configure your users and authentication without getting locked out of the Work Portal: 1.Perform the deployment with the authentication method set to Bizagi. This lets you access the Work Portal as the Admon user without providing any credentials. 2.Once in the Work Portal you can manually enter your users, or alternatively you can rely on the method of your choice to synchronize your users' information into the WFUser table (SOAP, Excel file, LDAP Synchronization, or performing a Data Synchronization procedure). 3.After having your users registered in the Work Portal, use the Management Console to set the authentication method to your preferred one.
If you plan on using LDAP authentication with periodic users synchronization, you may ignore the previous steps since you will only need to wait until the next synchronization happens for your users to be able to log into the 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.
•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 two supported protocols for federated authentication:
oSAML 2.0: With this protocol Bizagi delegates the authentication procedure to the third-party Identity Manager of your choice (Bizagi Supports integration with Entra ID, ADFS, NetIQ, Okta, PingFederate or 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.
oWS-Federation: This type of authentication is done by delegating the information to an ADFS server that has been configured to work with this protocol. The messages are sent using the WS-Federation and WS-Trust standards which uses SAML 1.1 assertions, which are not SAML 2.0 Compliant. For more information about this method, refer to WS-Federation.
|
Although for federated authentication there are two supported protocols. We recommend using SAML 2.0 over WS-Federation. SAML 2.0 is a common standard in the industry that can be compatible with a full range of systems in your organization. |
•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. 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 methods summary
The following table describes the most important characteristics of each authentication method, from the perspective of what you can do with it from Bizagi.
|
Single sign-on |
Same sign-on |
When to use it |
SAML 2.0 Federated authentication |
✔ |
✔ |
If you have an IdP |
WS-Federation |
✔ |
✔ |
If your IdP does not support SAML 2.0 |
OAuth2 - OpenID |
✔ |
✔ |
When federated authentication is not an option |
LDAP |
✖ |
✔ |
When Windows Authentication is not an option |
Bizagi |
✖ |
✖ |
If you want users and credentials to be managed independently by Bizagi |
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 make sure 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, 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 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").
There are alternative ways of populating your users information, refer to these articles for further information: •Synchronizing users via web services. •How to synchronize users from an excel file.
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. |
Authentication for multiple domains
If your project uses more than one domain, you can configure Multiple Authentication, you can use several authentication types and domains in your Bizagi solution. A domain refers to a specific group of users who share common parameters such as their location, area, corporation, among others.
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).
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.
Last Updated 9/11/2024 9:12:13 AM