Column-level security is specified in itemGroupAccessGrants. An itemGroupAccessGrantList defines default access to one item group. Within the group, access is granted by user role in itemGroupAccessGrants. Access to items within an item group can be specified by itemAccessGrants.
Column-level security passes from parent object to child object unless specified otherwise:
• | If access is unspecified for an object, the access of the parent object applies. If the unspecified object is an item in an item group, the item group’s access applies. |
• | If the unspecified object is an item in an item group that is nested in another item group, the access of the nearest parent item group applies to the item. |
If the nearest parent group’s access is also unspecified, that group takes its access from its parent group and passes it to the item. In this case (specified item group > unspecified item group > unspecified item), access for the item cannot be specified in an item-level grant.
• | If access is specified for an item group but there is no item group principal expression matching the current user, the user has the item group’s default access, not the item group’s specified access. |
If a matching item group principal expression does exist, the user’s access to items depends on access specifications, if there are any. Access to other items depends on the item group’s specified access.
If multiple item group principal expressions match the user (such as one expression for the user and one for his role), their access grants are combined, or ANDed, in a simple series. As a result, one denied statement overrides multiple granted statements.
Column-level security is defined as follows:
<itemGroupAccessGrants> <!-- Begin column-level security --> <itemGroupAccessGrantList id="expense_join_item_group_access_grant_group" label="aLabel" itemGroupId="expense_join" defaultAccess="denied"> <itemGroupAccessGrants> <itemGroupAccessGrant id="expense_join_super_user_item_group_grant" access="granted"> <principalExpression> authentication.getPrincipal().getRoles().any{ it.getRoleName() in ['ROLE_ADMINISTRATOR'] }</principalExpression> </itemGroupAccessGrant> <itemGroupAccessGrant id="ROLE_SUPERMART_MANAGER_item_group_access_grant" access="granted"> <principalExpression> authentication.getPrincipal().getRoles().any{ it.getRoleName() in ['ROLE_SUPERMART_MANAGER'] }</principalExpression> <itemAccessGrantList id="expense_join_ROLE_SUPERMART_MANAGER_item_grant" defaultAccess="denied"> <itemAccessGrants> <itemAccessGrant id="itemAccessGrant1" itemId="ej_expense_fact_exp_date" access="granted" /> </itemAccessGrants> </itemAccessGrantList> </itemGroupAccessGrant> </itemGroupAccessGrants> </itemGroupAccessGrantList> <itemGroupAccessGrantList id="expense_join_store_item_group_access_grant_group" label="aLabel" itemGroupId="expense_join_store" defaultAccess="denied"> <itemGroupAccessGrants> <itemGroupAccessGrant id="expense_join_store_super_user_item_group_grant" access="granted"> <principalExpression> authentication.getPrincipal().getRoles().any{ it.getRoleName() in ['ROLE_ADMINISTRATOR'] }</principalExpression> </itemGroupAccessGrant>\n <itemGroupAccessGrant id="ROLE_SUPERMART_MANAGER_store_item_group_access_grant" access="granted"> <principalExpression> authentication.getPrincipal().getRoles().any{ it.getRoleName() in ['ROLE_SUPERMART_MANAGER'] }</principalExpression> <itemAccessGrantList id="expense_join_ROLE_SUPERMART_MANAGER_store_item_grant" defaultAccess="denied"> <itemAccessGrants> <itemAccessGrant id="itemAccessGrant3" itemId="ej_store_store_type" access="granted" /> <itemAccessGrant id="itemAccessGrant4" itemId="ej_store_region_id" access="granted" /> <itemAccessGrant id="itemAccessGrant5" itemId="ej_store_store_name" access="granted" /> <itemAccessGrant id="itemAccessGrant6" itemId="ej_store_store_number" access="granted" /> <itemAccessGrant id="itemAccessGrant7" itemId="ej_expense_fact_exp_date" access="granted" /> <itemAccessGrant id="itemAccessGrant8" itemId="ej_expense_fact_amount" access="granted" /> </itemAccessGrants> </itemAccessGrantList> </itemGroupAccessGrant> </itemGroupAccessGrants> </itemGroupAccessGrantList> </itemGroupAccessGrants>
|
Elements of itemGroupAccessGrants are:
• | itemGroupAccessGrantList. List of access grants to one item group. Specifies default access to the item group and all items in the group. If you want to restrict access to items outside of any group or set, create an itemGroupAccessGrantList for them where the id of the group is "". |
• | itemGroupAccessGrant. Specifies access to the item group for one user role. |
• | principalExpression. Evaluation of the authentication object and user to determine the role to be granted or denied access. |
• | itemAccessGrantList. List of access grants to items in the item group. Specifies default access to the items. Overrides default in itemGroupAccessGrantList. |
• | itemAccessGrant. Specifies access to one item. |
In the above example, the progression of column access grants is:
• | Deny access to everyone. |
• | For each item group: |
• | Grant group access to administrator roles. |
• | Grant group access to additional roles. |
• | For each additional role, deny access to specific items or, alternatively, deny access to all group items, then grant access to specific items. |
Access is denied to everyone initially. Otherwise, all users would have complete access. Next, access to each item group is granted for administrator roles.
Next, access is defined for the SuperMart manager role. First, access is granted to each item group even though the access may be limited eventually. If access is not granted at the group level, the SuperMart manager has no access at all. Then, access to all items in the group is denied, followed by grants to specific items.
An alternative way to restrict access is to simply deny it on specific items. However, this method is not as secure as denying access to all items then granting access to some. The latter requires the programmer to specifically identify each item to which the role has access, which is more secure.
By default, all grants for a given role are ANDed. The ANDed series can be modified by an OR expression (orMultipleExpressions="true"). For instance, the following grants are implemented as A and B and C:
<resourceAccessGrant id="A">
<resourceAccessGrant id="B">
<resourceAccessGrant id="C">;
while these grants are implemented as (A or B) and C:
<resourceAccessGrant id="A">
<resourceAccessGrant id="B" orMultipleExpressions="true">
<resourceAccessGrant id="C">
The OR expression can be applied in grants for items and item groups as well as resources.
Elements of itemGroupAccessGrants are:
• | itemGroupAccessGrantList. List of access grants to one item group. Specifies default access to the item group and all items in the group. If you want to restrict access to items outside of any group or set, create an itemGroupAccessGrantList for them where the id of the group is "". |
• | itemGroupAccessGrant. Specifies access to the item group for one user role. |
• | principalExpression. Evaluation of the authentication object and user to determine the role to be granted or denied access. |
• | itemAccessGrantList. List of access grants to items in the item group. Specifies default access to the items. Overrides default in itemGroupAccessGrantList. |
• | itemAccessGrant. Specifies access to one item. |
In the above example, the progression of column access grants is:
• | Deny access to everyone. |
• | For each item group: |
• | Grant group access to administrator roles. |
• | Grant group access to additional roles. |
• | For each additional role, deny access to specific items or, alternatively, deny access to all group items, then grant access to specific items. |
Access is denied to everyone initially. Otherwise, all users would have complete access. Next, access to each item group is granted for administrator roles.
Next, access is defined for the SuperMart manager role. First, access is granted to each item group even though the access may be limited eventually. If access is not granted at the group level, the SuperMart manager has no access at all. Then, access to all items in the group is denied, followed by grants to specific items.
An alternative way to restrict access is to simply deny it on specific items. However, this method is not as secure as denying access to all items then granting access to some. The latter requires the programmer to specifically identify each item to which the role has access, which is more secure.
By default, all grants for a given role are ANDed. The ANDed series can be modified by an OR expression (orMultipleExpressions="true"). For instance, the following grants are implemented as A and B and C:
<resourceAccessGrant id="A">
<resourceAccessGrant id="B">
<resourceAccessGrant id="C">;
while these grants are implemented as (A or B) and C:
<resourceAccessGrant id="A">
<resourceAccessGrant id="B" orMultipleExpressions="true">
<resourceAccessGrant id="C">
The OR expression can be applied in grants for items and item groups as well as resources.