Security group permission definitions
In an i2 Analyze security schema, the mandatory
<SecurityPermissions>
element contains one or more
<GroupPermissions>
elements. Each <GroupPermissions>
element
defines the security levels that users in a particular group receive for items and records with
particular dimension values in an i2 Analyze deployment.
The syntax for defining the security permissions for user groups enables membership of one group to convey permissions across several dimensions, and allows different groups to convey different permissions for the same dimensions. The following example shows how to structure <GroupPermissions>
elements inside the <SecurityPermissions>
element:
<SecurityPermissions>
<GroupPermissions UserGroup="Clerk">
<Permissions Dimension="SD-SC">
<Permission ... />
</Permissions>
...
</GroupPermissions>
<GroupPermissions UserGroup="Manager">
<Permissions Dimension="SD-SC">
<Permission ... />
...
</Permissions>
<Permissions Dimension="SD-IT">
<Permission ... />
...
</Permissions>
...
</GroupPermissions>
<GroupPermissions UserGroup="Security Controller">
<Permissions Dimension="SD-GA">
<Permission ... />
</Permissions>
</GroupPermissions>
</SecurityPermissions>
The value of the UserGroup
attribute of each <GroupPermissions>
element must match the name of a group of i2 Analyze users.
The value of the Dimension
attribute of each <Permissions>
element must match the identifier of one of the dimensions that is defined in the first part of the schema.
It is normal for <Permissions>
elements for the same dimension to appear in more than one <GroupPermissions>
element:
- Users who are members of one group but not the other can receive different access levels on items and records that have the same dimension values.
- When users are members of more than one group,
<Permissions>
elements for the same dimension are combined before any access level calculation takes place.
<GroupPermissions>
elements from a
deployed security schema, if the resulting system continues to obey the rules of i2 Analyze. In particular, it must remain possible for all users to get
an access level that is not "none" for at least one value in every access dimension.