Change Management now supports a record rather than table level advanced security feature whose aim is to show users the type of change requests they want to create, and hide those that are not applicable to them. The User Criteria feature, grouping together user attributes such as role, group, location, department, etc and combinations thereof, provides this level of granularity of access through configuration.
This is a paradigm shift away from simple table level ACLs to a scripted record based set of ACLs, and presents a challenge in uptake. That challenge is to not modify existing Table level ACLs which has the potential to both lock users out of records as well as opening up records to users who should not see them. This ACL inertia impedes uptake of this feature because it requires administrators to both review and alter their ACLs, and this post intends to provide a path to helping admins make those changes.
There are three levels of security to think about when using this feature. To use the lowest level of security, i.e. the most granular, upper levels of ACLs should not allow a user through. Note that chg_model extends sttrm_model and so for explanation purposes these are the same. The difference is the sttrm_model can be mapped to any table that extends task, but chg_model is already mapped to change_request.
The idea is to shunt your security checks to the lowest, i.e. most granular level, such that Available for allows a user to see a change model and Not available for prevents a user from seeing a change model.
As we can see from the chart above, if a user cannot read the change_request table, that becomes a pre-requisite. If a user has a role, e.g. change_manager, and that role is allowed to read change models, hiding cannot be done at a more granular level. OOB SNC had shipped ITIL and sn_change_read roles at, this level, so for upgrade customers these remain in place. These should be removed after carefully reviewing and understanding the ramifications, i.e. removal mean potentially locking users out of these records and preventing them from creating Change Requests.
Also note that I am only giving read ACLs as examples, but a review and modification of write/create/delete may also be needed and follow the same pattern as read. The new SNC scripted ACL now runs at record level as shown below, i.e. it takes current (the change model record) and checks its RBAC and User Criteria.
Here is the write equivalent.
OOB SNC has pushed the ITIL and sn_change_read roles to RBAC level, i.e. roles that can read a change model, onto the change model. However if you want to hide things based on user criteria, consider removing these from RBAC into the lowest level. For ITIL you would create a User Criteria, users with ITIL role. Then you would add this to the list of Available for. Now things can be hidden from ITIL users, based on any of their characteristics e.g. create a user criteria that matches a department: X, and add that user criteria to Not available for. Now users who have the ITIL role, but are in department: X will not see Change Models which have the department: X user criteria in their Not available for list.
2 Comments
