Authentication security configuration and administration

<< Click to Display Table of Contents >>

Navigation:  Bizagi Engine > Bizagi system administration > Maintenance and administration > Environment administration >

Authentication security configuration and administration

Overview

Bizagi offers the possibility to manage the security settings of the project through the use of Bizagi Management Console.

Managing this information can be done separately in each of the project's environments: Development (authoring), Production or Test.

 

When opening Bizagi Management Console, you will access this configuration from the Security module:

 

MC_Security

 

Settings which are managed under the Security module include: The authentication type used (Authentication), access control settings (Authorization), and LDAP import settings.

 

 

Authentication settings

You may edit the type of authentication used by the project, and further parameters for the specific type of authentication.

 

Authentication1

 

Authentication types are:

Bizagi Authentication: Allows Bizagi to handle authentication itself (domain, users and their passwords are stored in Bizagi).

LDAP Authentication: Uses an LDAP Server (i.e Active Directory) to verify the information entered in the login page (username, password and domain).

While using authentication against an LDAP Server, passwords are not stored in Bizagi.

Federated Authentication: Uses an Identity provider that authenticates the user and facilitate Single Sign-On capabilities through federated services.

While using Federated authentication, passwords are not stored in Bizagi and the authentication in Bizagi is entrusted to that Identity provider which needs to comply with the WS-Federation Passive Protocol standard (i.e Active Directory Federation Services).

Windows Authentication: 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.

Windows authentication does not work in mobiles if Anonymous Authentication is disabled. In order to use it, you have to enable the Anonymous Authentication. This will skip the login page.

Custom Authentication: Allows 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).

Mixed Authentication: Allows using two different types of authentication for users from different domains. One of the types must be Bizagi Authentication, and the other type may be either Windows or Custom Authentication.

 

 

note_pin

Recall the following important aspects:

 

1. Authentication run on execution will require that any user wanting to log in to Bizagi is previously imported/created in Bizagi's database (even though, with certain authentication types, further information such as the password is not stored in Bizagi itself).

 

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 run the solution's administration (i.e modify parameter entity values, manage your users, licenses, cases, etc).

 

Further authentication parameters to modify, according to the specific authentication type are:

 

Authentication type

Option

Description

 

Bizagi

Account lockout duration

Defines the number of minutes an account remains locked out due to reaching Maximum number of failed login attempts (and having set Enable account lockout for failed login attempts), before automatically being unlocked.

This duration must be greater or equal than Failed login attempts time-out.

E-mail for an account unlock request - Body

Defines the body of the mail to be sent to the administrator when a user requests the unlocking of an account  (i.e when using Enable account unlock request e-mails to admin and specifying E-mail of admin).

Use with E-mail for an account unlock request - Subject.

E-mail for an account unlock request - Subject

Defines the subject of the mail to be sent to the administrator when a user requests the unlocking of an account (i.e when using Enable account unlock request e-mails to admin and specifying E-mail of admin).

Use with E-mail for an account unlock request - Body.

E-mail for an active account - Body

Defines the body of the mail to be sent to a user when his/her account is created and set as active.

Use with E-mail for an active account - Subject.

E-mail for an active account - Subject

Defines the subject of the mail to be sent to a user when his/her account is created and set as active.

Use with E-mail for an active account - Body.

E-mail for password reminder - Body

Defines the body of the mail to be sent when the user requests a password reminder.

Use with E-mail for password reminder - Subject.

E-mail for password reminder - Subject

Defines the subject of the mail to be sent when the user requests a password reminder.

Use with E-mail for password reminder - Body.

E-mail of admin

Defines the e-mail of the administrator of accounts in charge of receiving E-mail for an account unlock request (i.e when using Enable account unlock request e-mails to admin).

Enable account lockout for failed login attempts

Establishes if accounts should be locked out when a maximum number of failed login attempts is reached (to use with Maximum number of failed login attempts).

Enable account unlock request e-mails to admin

Establishes if e-mails are sent when a user requests an account unlock.

Use with E-mail for an account unlock request, and E-mail of admin.

Enable authentication logging in database

Establishes if an audit log is recorded with all authentication events.

Enable multiple sessions per account

Establishes if more than one simultaneous session is allowed for a same account.

Enable quick login

Applies only to the Development and Test environments.

 

Establishes if login to the Work portal is done without inputting the passwords of accounts (a quick login through a drop-down list displaying valid login accounts).

The drop-down list will show the first 100 active users (from the 101th user, accounts need to be typed into a text field).

To use for unit tests or quick prototyping purposes (this setting is not valid for a production environment).

Enable use of a secret question

Establishes if a secret question and answer can be filled out by users, in order to have the possibility of avoiding an account lockout when the password is forgotten.

Enable password change after the first login

Establishes if a user must change the password after the first login.

Consider using this option or setting an explicit number of days for Password minimum age.

Enforce password history

Defines the number of unique passwords an account must have before reusing an older one.

Enforce use of capital letters in passwords

Establishes if passwords must contain at least one capital letter..

Enforce use of letters in passwords

Establishes if passwords must contain at least one letter.

Consider using Enforce use of capital letters in password and Enforce use of lowercase in password instead.

Enforce use of numbers in passwords

Establishes if passwords must contain at least one number.

Enforce use of small letters in passwords

Establishes if passwords must contain at least one small letter.

Enforce use of special characters in passwords

Establishes if passwords must contain at least one special character (i.e non alphanumeric characters).

Enforce validation of sequences in passwords

Establishes if passwords are not allowed to contain character sequences (e.g: abc or 12).

Failed login attempts time-out

Defines the number of minutes in which failed login attempts time-out.

The counter that stores this number of attempts is reset after this time frame, provided that the Maximum number of failed login attempts is not reached.

Idle account duration before lockout

Defines the maximum number of days before an unused account is locked out (unused accounts are those which have not had activity in that time frame).

Idle sessions time-out

Defines the time in minutes in which an idle session expires; in which case it would be required to authenticate again.

In case you wish to increment this time-out to more than 60 minutes (not recommended), bear in mind that you will need to edit the default settings at your web server (e.g, doing so directly at the IIS).

Maximum length of passwords

Defines the maximum number of characters for passwords (use zero if a maximum length is not desired).

 

Maximum number of failed login attempts

Defines a maximum number of login attempts before an account is locked out.

Applies when Enable account lockout for failed login attempts is active.

 

Minimum length of passwords

Defines the minimum number of characters for passwords.

Consider using this option or setting an explicit number of days for Enable password change after the first login.

 

Password maximum age

Defines the maximum number of days in which a password can be used, before it requires to be changed (i.e, the expiration time of passwords).

 

Password minimum age

Defines the minimum number of days in which a password must be used, before it is available for a change.

SLA for an account unlock request

Defines the expected service time (in hours) to process an account unlock request.

LDAP

AUTHOPTIONS_LDAP_Path

Corresponds to the path to access the LDAP Server (using the LDAP URL format).

AUTHOPTIONS_LDAP_UseIntegration

Applies if you already have configured Bizagi to synchronize your Active Directory users into Bizagi.

If this is the scenario, turn this option on, to use the same LDAP URL and settings from the LDAP synchronization settings.

Custom

Custom Authentication Component

Defines the name of the assembly that will perform the authentication. This assembly must be present  in the Web application bin or in the GAC.

Custom Authentication Class

 

Defines the name of the class that will perform the custom authentication within the component specified. You will need to include the namespace of that class (set as Namespace.Class).

Mixed

Bizagi Domain

Specify the name of the domain for the users who will be authenticated using Bizagi Authentication.

Other Authentication type

Select which other type of authentication will be used (Windows or Custom).

 

 

Authorization settings

You may edit the authorization settings to modify the restriction on end users which can modify or view certain information and use administration options in the project.

Access rights to the different elements of the Work Portal are managed through the definition of roles and user groups.

 

 

Security3

 

In the Authorization component you can manage access to the following items:

 

MENU

DESCRIPTION

Analysis

 

Allows or denies access to specific Processes' information in the various Process Analysis Tools.

 

If access is denied for a specific Process, you will able to access the Reports menu, but you will not be able to view that Process in the Business Activities Monitoring BAM, Sensors Analytics and Process and Task Analytics.

Applications

Allows or denies access to applications. These permissions are granted for each application individually.

 

If permission is denied for a specific application, then you will not be able to create new cases of any processes that belong to that restricted application; nor will you be able to view cases related to such processes in your Inbox.

 

Be aware that you are still able to be assigned to tasks of a Process that belong to a restricted application, despite not having access rights to the application.  For this reason take care when implementing this restriction.

Entities

Allows or denies administration privileges for Parameter entities in the Work Portal. These permissions are granted for each entity individually.

 

The administration privileges that can be set are:

 

Full Control: Permits total administration of an entity, that is, if allowed, you will be able to create new records of the specified entity as well as view and modify existing entities.

 

View Data: If allowed, you will be able to view records of the entity only.  Changes to data will not be permitted.

 

Modify: If allowed, you will be able to view and modify the records of the entity, but not to create new records.

 

Create: If allowed, you will be able to create new records for the entity, but not to modify the existing records.

Manage

Allows or denies the management of Alarms, Asynchronous Work Items, Cases, Default Users and Profiles.

New Cases

Allows or denies the creation of new cases. These permissions are granted for each process individually.

 

If permission is denied for a specific Process, you will not be able to create new cases of that Process; however, you may still be assigned to activities belonging to such a restricted process.

Pages

Controls access to the menu and submenus pages of the Work Portal.  These permissions are granted for each page individually.

 

IMPORTANT: In the Analysis menu, the permissions applied to All Reports cascade down to all sub-menus.  This means that if access is denied in All Reports you will not be able to access any of its features or lower level directories (sub-menus).

 

Policies

Allows or denies access to policies. These permissions are granted for each policy individually.

 

If access is denied for a specific policy, the restricted policy will not be visible in the Business Policies menu of the Work Portal; consequently, you will not be able to gain access to it.

Queries

Allows or denies access to case queries. These permissions are granted for each query individually.

 

If access is denied for a specific query, the related form of the restricted query will not be visible in the Queries menu of the Work Portal.

Vocabularies

Allows or denies access for vocabulary management. These permissions are granted for each definition individually.

 

If access is denied for a specific definition, the vocabulary definition will not be visible in the Business Policies menu of the Work Portal; consequently, you will not be able to modify it.

 

 

LDAP import settings

You may edit the connection and configuration parameters of the import of users from your LDAP system.

 

MC_LDAP

 

When editing specifics on the connection to your LDAP and how the synchronization of users will be carried out (i.e scheduled at what time frame), consider these settings:

 

Setting

Description

Connection

LDAP URL

Specify the URL path to access the LDAP server (LDAP URL format).

Domain\username

Specify a username and its domain, to be used as the authenticated user performing the synchronization.

Password

Specify the password for the domain's username used as the authenticated user performing the synchronization.

Synchronization hour

Define an hour of the day in which the Scheduler will perform the LDAP synchronization.

Allowed values for this field are 0 to 23.

Import settings

Filter

Input a filter to import only the proper accounts into your project (according to an LDAP attribute criteria).

It is strongly recommended to use and set a filtering condition in order to import the proper set of users (specially when testing the configuration).

View more information about filter options at LDAP attributes.

Domain

Specify the domain name to which the users will be registered in Bizagi's user entity (WFUser).

User account identifier

Choose the LDAP attribute which identifies in an UNIQUE manner each account. For example, sAMAccountName is the common LDAP attribute corresponding to an user's account name.

 

When editing the attribute mappings (which information incoming from your LDAP is updated in Bizagi users), consider adding, editing or deleting mapping rows under the definition of the Attribute mapping tab:

 

LDAP02

 

When editing the default values taken by some of the fields of information of users in Bizagi, consider adding, editing or deleting rows under the definition of the Default values tab:

 

 

LDAP03

 

note_pin

Do NOT specify that the enabled attribute is set to true, unless you are completely certain that your current license will support the number of imported users.

Keep in mind that if the total number of active users is greater than the number of licensed users, then the Work Portal will stop working.

 

Recall that you may test this configuration (i.e. specially recommended if you changed critical aspects such as the LDAP filter), so that you are shown with the records found at Test results:

 

LDAP04

 

note_pin

Testing the configuration does not imply that an immediate synchronization is carried out at Bizagi's database.

This is only for testing purposes and not persisted, since the Scheduler service will be in charge of executing your final configuration.

 

Important

The options presented in the Security module for the Authentication options and LDAP synchronization in your Bizagi project, may be initially defined in the Development environment for the Production environment (that is, using LDAP or any other configuration related to the Work Portal's authentication method).

 

Once after your project has been deployed to Production, these settings for that environment may no longer be edited directly in the Development environment (they must be made from the Management Console).

For the Test environment, values can be redefined in the Development environment (through Bizagi Studio), so that a new deployment overwrites those values.

Summarizing, changes in the Authentication and LDAP already defined in Production, needs to be done directly in that environment (by using the Management Console).

 

note_pin

This does not include the Authorization configurations, which can be both: Managed in Production directly through the Management Console, and are always overwritten in Production with the incoming values in Development (when executing a deployment).