This friendly little reminder comes via Scott Mann from University of South Florida:
I found something in our site that I wanted to pass along for the benefit of your developers (yes, we’re still finding stuff). Today’s issue is that we were getting email failures for people we knew had access to projects. They were failing on the Reschedule activity which is supposed to notify the PI and reviewers that the project has been moved to another meeting. Unfortunately, the notifications were configured on the activity, whose read policy properly blocks the PI since the form displays the names of reviewers. Since the notification’s context is the activity, and the recipient does not have access to the activity, the notification fails. It’s an easy mistake to make, but a good lesson for understanding the impact of activity security and the importance of context.
First let me say thanks to Scott for his contribution. It’s nice when others write my blog posts for me. ;-) This is a first but hopefully not the last (hint, hint, nudge, nudge). Scott is absolutely right and makes a point that I think deserves further elaboration.
When it comes to security, most traditional enterprise systems make a real point of highlighting the fact that they have “role-based security” as if that’s all that is really needed. In the real world, however, role-based security alone doesn’t allow us to effectively answer the question “Can user x see the details of protocol y?" or Can user x update the information in project y?”. It’s not sufficient to define a security rule that allows all users with a PI role to update IRB Protocols or Funding Proposals. To accomplish this, more is required. What is needed is both Profile-based security and Contextual security. This is what is supported by Click Commerce Extranet.
Profile-based security allows us to define rules to answer questions like “What kinds of users have the ability to perform a certain action in the system?”. For example, what kind of users can see the Meetings page in the site? One way to define a class of users is by their role(s). Role-based security is a subset of what can be accomplished with this style of security but extranet goes beyond that, allowing you to secure content based upon not only role but organizational affiliation, the type of organization, specific user, and even their incoming IP address.
Profile-based security is often sufficient to secure site content such as pages and site documents. When it comes to your workflow processes, however, knowing how a user is associated with the information being secured is a critical element. To support this, Extranet introduces the notion of contextual security. By combining the two, we are then able to define security policies like Users with a role of Registered user are able to edit IRB Protocols if they are assigned to the protocol as the PI or Study Staff”, Policies like these are configured as part of the workflow definition. As policies, they can be defined once and be evaluated at run time.
Security policies can be defined on Person, Organization, specific Project Types and their specific Activity Types. There’s a lot more to say about different ways to configure Security Policies and best practices around avoiding performance pitfalls, but this article is about context so now that you know about contextual security, we can get to the heart of the matter…
Security Polices are always defined on a specific data type (Study or Funding Proposal) but are evaluated against specific entities (“PRO00002321”, or “FP00001988”). It’s the entity that provides context.
Let’s use the following example policy:
”I am allowed to edit the Study if I am defined as a member of the Study Team on the study and the study is in Pre-Submission”
In this case the Security Policy is defined on the Study Project Type and the context is the specific study. This is a simple case. The system will allow the current user to edit the study if it’s status us Pre-Submission and the current user is a part of the Study team specified on the study. The context is the study.
So now let’s use the following example policy:
“I am allowed to submit the Study for review if I am the PI on the Study.”
In this case, the policy is defined on the Submit activity type. Even though the policy is defined on the Activity type, the context is the specific study the user is wanting to submit for review. The system evaluates this policy by verifying that the current user is specified as the PI on that study. If they are, the test passes and the the user is allowed to submit. The context is still the project because that’s where the contextual data lives.
If no policies are defined on the activity, the policies on the Project Type are evaluated by default. If the user is allowed to edit the project, they are allowed to execute the activity. When defining policies on the Activity type, you are in effect electing to override the default security policies for that given activity.
This notion of context carries into other areas of your workflow configuration, including Email Notification Rules. When an email notification rule is configured on an Activity type, the context of the notification is the logged activity. If, on the other hand, the email Notification Rule, is configured on the State Transition, the context is on the project itself. What entity serves as context is significant in that the notification system within Extranet prevents a user from being sent email when they are not allowed to read the context. This means that, for an Email Notification triggered by the execution of an activity, the user will only be sent the email if they are allowed to read the logged activity as determined by evaluating it’s security policies.
In Scott’s example above, he ran into the case where the user was able to view the project but not the logged activity. The fact that the notification was configured on the activity and thus had the logged activity as it’s context meant that the email was not sent.
More information on managing your security policies can be found in the Workflow Configuration Guide on ClickCommerce.com.
Cheers!
No comments:
Post a Comment