A way to think about Security Policies

Anyone who has done any configuration within Click Commerce Extranet has most likely had to configure the security policies. These policies are an essential part of any fully configured site. It’s those policies that define who can access project information, perform Activities, interact with Reviewer Notes, and view information in the project’s audit trail. Proper configuration of Security Policies is critical to your site’s success for two primary reasons: Making sure the right people can do the right things at the right time and avoiding poor performance.

Even if you’ve configured security policies before, this post should be useful as it describes a way of thinking about how best to configure your policies.

A single Security Policy allows you to inform the system on how to answer two fundamental questions:

• Who has access?
• What can they access?

Additional policies are then added to identify other target audiences and what they can access. Below is an example of policies that define read access to IRB protocols. This screen is a good illustration of the fact that each Policy is comprised of 5 pieces of information:

1. The type of item being secured. In this example, we’re securing access to IRB Protocols.
2. The action that is being secured. At the moment, we’re looking at the list of policies that define read access.
3. The target audience for each policy. This is defined through standard permissions and configured by clicking on the padlock icon.
4. A definition of what data is exposed through each policy. This is defined by clicking the “Edit” link on a given policy.
5. The policy’s priority. This determines the order in which the policies will be evaluated.

Priority is arguably the piece least leveraged, but using it effectively can have significant benefits in both performance and accuracy of your policies. To help, I offer a way of thinking about how to incorporate priority into your configuration. I call the approach, the “Inverse Triangle Method” (I’m open to suggestions on a snazzier name as I obviously wasn’t feeling very creative that day).

The Two Triangle Method

Priority determines the order in which the system will evaluate the defined Security Policies for a give Data Type and Action. By default, the first policy for which the user qualifies based upon the defined policy permissions is the one that is “in effect” for the user. This means that the user has access to all the data exposed through that policy. This is how things work when the Execution Mode is “Single Policy”. I’ll talk more about the impact of “All Policy Mode” in a bit. For now, I’ll just say that “All Policy Mode” should be used only when “Single Policy Mode” cannot meet your needs.

Since, the evaluation of your policies stop when the first one for which the user qualifies is found, the priority order is critically important. When thinking about how best to order them I keep this image in my head.

The blue triangle represents the target audience for each audience. The highest priority policies should be those restricted to the fewest people. At the top of the list, you would put the policies available to Site Managers and high level administrators. You would then position policies available to the widest audience such as Registered User) at the bottom of the list. The reason you do this is because an Administrator would typically also be a member of the wider audiences. They are most definitely going to be a registered user so if the policy for registered users were prioritized above the Administrator policy, the wrong policy would be in effect for them.

The green triangle represents the breadth of data that the user can access. As it happens, the users with the greatest privileges in your site will typically have access to the greatest breadth of data. It’s common, for example, for an IRB Administrator to be able to see all IRB Protocols. As we travel down the green triangle, the number of projects a user is allowed to access decreases. Registered users without any additional roles, for example, may only be able to see the IRB Protocols they are directly involved in.

If your policies are not ordered in this way, you run the risk of a privileged user  not being able to access all the data they need to accomplish their job. This is because they will first qualify for a policy with a narrow data scope.

Now a final mention of “All Policy Mode”. This feature is intended to be used when Single Policy Mode isn’t sufficient. It’s a big hammer because when in this mode, the system will process all policies for which the user qualifies rather than just the first one found in priority sequence. There is a significant performance cost to doing this. I have seen cases where a site had issues in that the priority sequence was not correct resulting in a group of users not being able to access projects and the “fix” was to switch to All Policy Mode. I’m not saying that there aren’t times when All Policy Mode is needed. That’s why the feature is there. In many cases, however, it’s used for the wrong reason. A review of the defined policies and their priority should be your first step in troubleshooting problems like these because if you can avoid use of All Policy Mode and avoid complex searches your site will perform better and your users will thank you.

Cheers!