Overview
Disregarding the selected Authentication type for your Work Portal login, you may choose to configure a schedule in Bizagi to import and synchronize users from your LDAP Server into Bizagi.
With this option, Bizagi will run a daily job to keep up-to-date the accounts' information (residing in an LDAP Server in your organization).
Keep in mind that passwords will be queried according to the selected Authentication type (meaning, that if you choose LDAP or Windows Authentication, Bizagi will not store any passwords).
Before you start
To set user synchronization using LDAP make sure that you have the following:
•LDAP URL in LDAP format. (LDAP using SSL is supported).
•Username and password be able to read user's information.
What you need to do in Bizagi
To both set and test the LDAP synchronization in your project, you need to enter the configuration details to your LDAP server, such as: URL, connection credentials and import settings or mappings.
This is done easily through three tabs, in these steps:
1. Entering the connection and import settings
2. Specifying attribute mappings
3. Defining default values (if any)
4. Testing and saving your configuration
|
You may also choose to modify later these settings for a specific environment in your project (Test or Production environment). To review or modify LDAP synchronization in a given environment, use Bizagi Management Console. |
1. Entering the connection and import settings
This initial configuration is done in the first tab called Basic configuration.
To do this, first enable the LDAP synchronization by marking the Enabled checkbox.
Then, make sure you fill out both the connection and import settings as described below:
Setting |
Description |
|
|---|---|---|
Connection |
LDAP URL |
Specify the URL path to access the LDAP server (LDAP URL format). LDAP using the SSL protocol is supported.
URL can start in any of these ways: •LDAP// •LDAPS// |
Domain\username |
Specify a username and its domain, to be used as the authenticated user performing the synchronization. Such user needs read access to these definitions. |
|
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.
If you wish for Bizagi Studio to perform the initial synchronization immediately, then you may input the current hour in which your server is at. For example, if it is currently 14:35, then you may input 14.
If you are using Automation Service (cloud), the hour of the synchronization is based on UTC. |
|
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 (especially 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. |
|
|
If the the "domain" field in the import setting section is left empty, then any user whose LDAP data doesn't include a domain will not be synchronized. If you want to synchronize these users you can include a Default value for the users that don't have an LDAP domain.
|
In this example, we set all these values:
|
Note that you may define the connection and all relevant LDAP import settings separately for each of your different environments (Development, Test and Production).
An initial deployment (the very first one) will publish this configuration to each environment. Henceforth, changes to the LDAP import settings need to be done locally (managed separately) in each environment. |
We strongly recommend applying a filter to exclude records that have empty or null values for the following fields: contactEmail, fullName and the account identifier field.
2. Specifying attribute mappings
LDAP accounts information is synchronized into Bizagi's WFUser System Entity.
By specifying attribute mappings you define in which WFUser attributes is the incoming information stored.
Move on to the next tab called Attribute mappings and make sure you add the necessary mappings for your WFUser attributes.
To do this, first click the Add Mapping button.
Select attributes from the WFUser Entity and match them to an LDAP attribute, which has the incoming information:
You can map to any attribute of your WFUser. The only exception is the idUser attribute, this ensures the integrity and consistency of your data.
Note that in this example we illustrate mapping the mail and name attributes since these 2 are explicitly required in Bizagi (contactEmail and fullName).
The following is the list of the default values available to be mapped.
The attribute used as the account's identifier is mandatory, it cannot be null.
Attribute |
Data type |
Comment |
|---|---|---|
contactEmail |
String |
Sets the email of the user. It is a mandatory field (cannot be null). |
CreatedCasesSkipAssignRules |
Boolean |
Identifies if the cases should skip allocation rules in development or test environments when created by this user |
DelegateEnabled |
Boolean |
Identifies if the user has the delegation enabled |
domain |
String |
Identifies the domain of the user. It is a mandatory field (cannot be null). |
enabled |
Boolean |
Identifies if the user is enabled in Bizagi |
enabledForAssignation |
Boolean |
Identifies if the user is legible for allocation of tasks |
fullname |
String |
Sets the full name of the user. |
idArea |
Integer |
Identifier of the Area of the user. Table AREA. * |
idBossUser |
Integer |
Identifier of the user in the Table WFuser.* |
idDelegate |
Integer |
Identifier of the user in the Table WFuser.* |
idLocation |
Integer |
Identifier of the Location of the user. Table LOCATION. * |
idTimeZone |
Integer |
Identifier of the Time zone of the user. Table BATIMEZONE. * |
idWorkingTimeSchema |
Integer |
Identifier of the working time of the user. Table WORKINGTIMESCHEMA. * |
language |
Integer |
Identifer of the language |
notifyByEmail |
Boolean |
Identifies if the user sholud receive emails sent by the solution, for automatic and customized notifications. |
userName |
String |
Sets the username. This field is mandatory (cannot be null) |
userStartPage |
Integer |
Configures the landing page of the user when they log in. It is used when the user is associated to a Persona, otherwise the default page is the Inbox. Choose from: 1. Automatic (default): Me if associated to a Persona of Inbox if not. 2. Inbox: Always opens the Inbox 3. Me: Always opens the Me page.
|
* Filed available to for on premises installations, given that the identifier is retrieved from the database.
|
It is required that you map: •contactEmail •UserName •domain: Bizagi recognizes domains in strings such as "domain\username" and "username@domain"
Quick facts that will help you design the synchronization 1.None of the three above fields should be NULL or blank. 2.The username + domain combination defines uniquely users in Bizagi (no two users can have the same username + domain combination). This is also important to bear in mind when doing the sync, because finding a same username + domain will have Bizagi assume there is an update to an existing record. 3.Usually username is taken from userPrincipalName or sAMAccountName. 4.When Bizagi receives a value (identifier) that is not valid, it is ignored. 5.Objects not listed in the table above should be ignored as those fields have been deprecated (i.e. offlineForms) |
3. Defining default values (if any)
This step is optional and recommended to define any default values for the WFUser attributes. Move on to the next tab called Default values and add any necessary default values for your WFUser attributes.
To do this, first click the Add Default value button.
Select attributes from the WFUser Entity and assign to them a value:
4. Testing and saving your configuration
Once you have finished your configuration, you may click the Test button to see your synchronization results.
Notice that this can take a while if you have a large number of users and therefore, it is recommended to use a filtering criteria.
You will be shown the records found in last tab called Test results
|
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. |
Finally, save your configuration.
The synchronization of the LDAP accounts (objects) is carried out by the Scheduler service in your project. Therefore, to initialize this synchronization and actually see your users in your Work Portal, you will need to restart the Environment. You may do this by using a maintenance Window. The Scheduler's job will start to execute the synchronization at the defined hour. When this has been completed, the LDAP users will be automatically created as Bizagi users.
To check for information about the executed synchronization (inserted and updated values), you may check the detail Bizagi saves in the Scheduler's trace.
Detail for this, would begin the line as INFO_LDAP at the Scheduler’s log file.
|
If a user is no longer found at the LDAP server, then Bizagi will disable that user (a logical deletion; not physical) in its import as well. |
Last Updated 6/9/2023 3:28:52 AM