Mapping roles to security groups

It is best to establish the security groups that you want to map to the access roles before building your file plan. Security groups are mapped to access roles when setting up a new FPOS object store, which typically happens for the first time during initial software installation. The security groups are established on the FPOS object store during object store creation and mapped to the security roles as part of the initial object store configuration process.

Knowing which security groups to map to each of the Enterprise Records security roles is important. The most flexible approach is to create one master security group for each of the Enterprise Records security roles. You can then later use the directory service to assign specific groups and users to the master security groups without having to change the security role mappings in

Enterprise Records.

Establishing master security groups

In Table 4-1 on page 100, we illustrate four security groups where we use a naming convention that associates the groups with Enterprise Records and identifies the role to which each group applies. These groups need to be established in the directory service with the intention that they will contain other groups as members. Therefore, we refer to these groups as

master security

groups

probably add other groups that have individual users as members. The naming convention that we chose here is merely an example. Most organizations establish their own standards and policies for naming security groups.

Table 4-1 Mapping security roles to master security groups

Figure 4-1 shows an example security mapping between roles and master groups for an example FPOS object store. This information can be accessed through the Enterprise Records desktop Administration view by selecting the FPOS repository and viewing the Security Script tab. This mapping is established during the initial configuration of the FPOS object store. Although the mapping can be changed by adjusting which groups are used for each role, the change in mapping does not apply to objects already created. So, it is best to establish this mapping before building out the file plan configuration.

Figure 4-1 Example security mapping between security roles and LDAP groups

Security roles Example master security groups

Records Administrator IER_RecordsAdminG Records Manager IER_RecordsManagerG Records Privileged User IER_PrivilegedUserG

Records User IER_RecordsUserG

Preferable practice: Work with your security administrator to establish an

appropriate naming convention for your security groups before implementing your Enterprise Records solution.

Using the predefined security configuration

When setting up the initial security configuration as just described with one master security group for each of the record management roles, it is possible to use the system without further differentiating groups of users. You can assign users directly to these master groups. However, most organizations have existing policies in place where directory services group memberships have already been established according to the employee’s role in the organization. In the long run, it is easier to maintain the mapping of employees into the various security roles by assigning existing organizational groups to the master Enterprise Records security groups.

Assigning existing groups to the master security groups

After you have established the master security groups, you can assign any other security groups to these master groups to give those groups access to Enterprise Records. For example, you might already have a group called

Example_RecordsCenterStaff. This group can be added as a member of IER_RecordsManagerG to give all the users who are members of the Records Center full Records Manager access.

The advantage of this approach is that it enables you to adjust security on an ongoing basis without having to remap groups to roles directly in Enterprise Records. You simply adjust security by manipulating group memberships within the directory service.

In Table 4-2 on page 102, we provide an example that shows how you can manage existing security groups in your organization by establishing group membership rather than changing the direct mapping of security roles to the master security groups. In this particular example, we assume that all members of the Example_IT_P8Admins group will be involved as Records Administrators. We can easily establish a specific IT departmental group just for Records Administrators as well. Similarly, in this example, we assume that all of the members of Example_RecordsCenterStaff will be acting in the capacity of Records Managers. We can easily establish specific groups to break down the records center staff into subgroups, part of which serve as Records Managers and others who might more appropriately be privileged users.

Table 4-2 Assigning organizational groups to the master IBM Enterprise Records security

groups

When you nest security groups, there are obviously many ways to go about arranging your organizational groups. Groups are often organized based on the functional roles of individuals within the organization. A single user can be a member of more than one organizational group, because that person might have multiple roles in the organization. The IBM Content Platform Engine security model will grant the highest level of access to a user who might be in multiple groups where those groups are used to control access to the same object. When using nested groups, always consider the performance impact that might arise if there are a large number of nested groups.