HR Security Evaluation: ACL's and COE Security Policies

[Willem]

HR Security ACL's and COE Security Policies

HR is slightly different from the rest of the Platform, as it provides us with COE Security Policies in addition to ACL's. To create the COE Security Policies, please find the Docs article here: Create a COE security policy 

In a future article I will share some of the Best Practices on setting up your COE Security Policies to help secure your HR Case data.

Evaluation

To help understand how the security is evaluated, and who gets access, I have created the following image:

• It will first determine if the logged in user is impersonating another user. If so, it will deny access to the case (depending on your configuration. See step 5 of this article:HR Security setup: (HR) Admin ).

• Then it will determine if the user has one or many HR Role(s).
  If yes, the User is an HR Professional. If not, the user is an Employee.

HR Professional

• Are there COE policies that match the HR Case table/COE the user is trying to access?
  No policies = Access (⚠️Note: This means if you have not set up any, all HR Professionals will have access!)
• If there are policies found, it will review them and allow or deny based on Group membership in the mentioned groups of that COE Security Policy.
• If based on the roles or policies the HR Professional does not have access, the system will (double)check if the user could have access based on the Employee checks (see @rhysbrennan comment).

Employee

• Approvers are allowed access.
• Opened by is allowed access.
• Opened for is allowed access.
• People on the Watch list are allowed access.
• Collaborators are allowed access.
• If the user has access to the Parent record is allowed access.
• Assignee of the task is allowed access.

Edit 20/06/2023 based on @rhysbrennan remarks of the Employee check that happens after HR Professional fails policies.

[rhysbrennan]

Hi Willem,
Thank you for the article it was a great help to us unpacking a problem we have with COE Security. I'd like to add that I think there is an inaccuracy (at least from what we found in our instance) because the flow looks more like this:

If you create a HR case, and you are a HR Professional you can read and edit the case even when COE Security fails. For us this is major concern because we expect some HR records be only be accessed by certain groups. We don't have a solution but this is what we found:

When the ACL's run it calls the sn_hr_core.hr_Case script include's canReadCase function. If they have a sn_hr_core.case_reader role; then COE Security is evaluated. If that fails then it will call this:

That then checks if they are the subject person and the subject person can read the ticket (from the HR Service Config) OR if the user can edit the case from the canEditCase function.

The canEditCase case function skips COE security checks because it failed in the canReadCase function, but will always allow the following roles to read the case:

• Opened By
• Opened For
• Watch List
• Collaborators

[Willem]

Thank you for this amazing addition@rhysbrennan. You are right on script evaluation order and that it will check for the left side for HR Professionals as well.

I made the choice to split involved scripting and logic. Logic wise the checks you describe are the "Employee" checks. So the logic described there will be followed. Completeness wise you are correct. I tried to find a balance between completeness and simplicity. Perhaps a doted line will add this nuance, I will update this later today and credit your comment. 

I have a more detailed description and visual in the pipeline. Will definitely tag you in that one and credit/link to your comment as well.

[cwillard]

If there are no COE policies, and the user is HR, what could be preventing them from seeing cases? 

[Nat Iyer]

Thanks for sharing the knowledge! You guys are awesome! 👏

[Markus6]

Hi,

I believe one important thing should be added here: Even if you are not part of the listed Group in a COE, but part of a child-group, you will get access as if you would be a member of the parent group.

The ACL and corresponding script includes use the "getMyGroups()" function which returns parent groups as well. This directly conflicts with what is displayed in the policies.

Kind Regards

Markus