Multi Tenants in Decision Center IBM ODM 8.0.x
A friend and colleague today asked me a very good question so as I spent one hour on it, I think it makes sense to share the information with IBM ODM 8.0.x users.
The request is what are the best practices and governance approach to follow for supporting multiple 'tenants' in IBM ODM Decision Server? In Decision Server there are different user groups, each group may be responsible of multiple projects, but users in the group could not see projects of other groups.
Obviously this is supported by the product out of the box, but it is important to follow some practices.
First it is important to understand the synchronization architecture as describe in Synchronization architecture. As a long time best practice it is important to synchronize a rule project from Design to Decision Center (DC) when the BOM is stable, but in fact there is an alternate approach is to define empty project in Decision Center as soon as your development effort starts. The rule project name has to be defined as it represents the top synchronization point between Rule Designer and DC.
The first synchronization has to be done by and administrator role, as stipulates in Publishing projects to Decision Center: "you must have administrator rights to Decision Center to publish a project initially to it". This is logic as permission settings are done by super users once the project is in the rule repository. Basically a developer creates a rule project, with the final expected name, gives his workspace to an administrator, and lets the administrator creating the rule project into Decision Center and set the permissions. Let see how to do that.
Suppose you have 3 groups of users defined in LDAP or WAS Federated Respository: UserGroup1, UserGroup2, and UserGroup3. (Use WAS admin console > Users &Groups management > Manage groups.
For each group define users with the Decision Center predefined role of 'rtsUsers' so they can login to DC and author rules. As in each group there is one administrator, for example Adam is part of UserGroup1 and has rtsAdministrator role, define the following group assignment.
This administrator is the person who can create projects in Decision Center for the first time. The table below presents an example of user allocations.
Recall that to use Decision Center project security as well as its permissions mechanism, all groups (except rtsAdministrator) must be declared in both the application server and Decision Center. To do so use the Installation wizard: Configure > Administration. Installation Settings Wizard > Step 3: Setup Groups. Then use the New button.
Now suppose that each group has the following rule project ownership:
After synchronizing the first time the LoanApplicationValidation-rules rule project from rule designer
Adam (administrator of user group1), connects to Decision Center and sets the 'branch security' using UserGroup1. Configure > Security . Edit Branch Security. (Select 'Enforce and configure security..." toggle)
From now only users in UserGroup1 can access the ruleset LoanApplicationValidation-rules. Until the branch security is not set on a rule project, this project is visible by all rtsUsers or rtsAdministrators users. Therefore it is recommended to enforce security, as soon as a project is synchronized from Rule Designer to Decision Center. There is a time window when other users may see this project as part of the list of possible projects in the Home tab. This is not a problem if you follow the practice of creating a simple, mostly empty project.
As each project already presents in Decision Center has its security permission set, other users in other group do not see rule projects not controlled by his/her group.
The request is what are the best practices and governance approach to follow for supporting multiple 'tenants' in IBM ODM Decision Server? In Decision Server there are different user groups, each group may be responsible of multiple projects, but users in the group could not see projects of other groups.
Obviously this is supported by the product out of the box, but it is important to follow some practices.
First it is important to understand the synchronization architecture as describe in Synchronization architecture. As a long time best practice it is important to synchronize a rule project from Design to Decision Center (DC) when the BOM is stable, but in fact there is an alternate approach is to define empty project in Decision Center as soon as your development effort starts. The rule project name has to be defined as it represents the top synchronization point between Rule Designer and DC.
The first synchronization has to be done by and administrator role, as stipulates in Publishing projects to Decision Center: "you must have administrator rights to Decision Center to publish a project initially to it". This is logic as permission settings are done by super users once the project is in the rule repository. Basically a developer creates a rule project, with the final expected name, gives his workspace to an administrator, and lets the administrator creating the rule project into Decision Center and set the permissions. Let see how to do that.
The Decision Center needs to support different groups of users, with the constraint that users part of one group could not see other rule projects managed by other groups, and even administrator role within a group could not see other projects. There is only a super administrator of the Decision Center server. It is for example rtsAdmin. Most of the time you do not need to manage projects. You need user who may be part of the rtsAdministrators group and other group of users.
Suppose you have 3 groups of users defined in LDAP or WAS Federated Respository: UserGroup1, UserGroup2, and UserGroup3. (Use WAS admin console > Users &Groups management > Manage groups.
For each group define users with the Decision Center predefined role of 'rtsUsers' so they can login to DC and author rules. As in each group there is one administrator, for example Adam is part of UserGroup1 and has rtsAdministrator role, define the following group assignment.
This administrator is the person who can create projects in Decision Center for the first time. The table below presents an example of user allocations.
| User | Group | Permission |
|---|---|---|
| Adam | UserGroup1, rtsAdministrators | Create rule project and set permissions |
| Bea | UserGroup2,rtsUsers | Author Rules |
| Eli | UserGroup1,rtsUsers | Author Rules |
| Val | UserGroup2, rtsAdministrators | Create rule project and set permissions |
Recall that to use Decision Center project security as well as its permissions mechanism, all groups (except rtsAdministrator) must be declared in both the application server and Decision Center. To do so use the Installation wizard: Configure > Administration. Installation Settings Wizard > Step 3: Setup Groups. Then use the New button.
Now suppose that each group has the following rule project ownership:
| Group | Rule Projects |
|---|---|
| UserGroup1 | LoanApplicationValidation-rules, & LoanApproval-rules |
| UserGroup2 | RiskAssessment-rules & DynamicTaskRoutingRules |
| UserGroup3 | Pricing-rules |
After synchronizing the first time the LoanApplicationValidation-rules rule project from rule designer
Adam (administrator of user group1), connects to Decision Center and sets the 'branch security' using UserGroup1. Configure > Security . Edit Branch Security. (Select 'Enforce and configure security..." toggle)
From now only users in UserGroup1 can access the ruleset LoanApplicationValidation-rules. Until the branch security is not set on a rule project, this project is visible by all rtsUsers or rtsAdministrators users. Therefore it is recommended to enforce security, as soon as a project is synchronized from Rule Designer to Decision Center. There is a time window when other users may see this project as part of the list of possible projects in the Home tab. This is not a problem if you follow the practice of creating a simple, mostly empty project.
As each project already presents in Decision Center has its security permission set, other users in other group do not see rule projects not controlled by his/her group.
Comments