BackgroundThere are use cases when it is useful to assume a user has permissions to an object simply because she has access to another object. For example, if a user is assigned to a Smart Worklist Member, we can reasonably assume she needs to be able to read the associated Smart Worklist and Smart Worklist Template. To facilitate this, AbstractObject includes a protected property called InheritedUser.
Assume a user has permission to call SmartWorklistMember/Next. In order to properly assign a user to the Smart Worklist Member, several other records must be read, and possibly written to, including Smart Worklist, Smart Worklist Template, and often the parent object to which the Smart Worklist Member is bound (e.g. a Loan). Without the concept of InheritedUser, the security administrators would need to ensure the user has: - functional permission to SmartWorklistSelect, SmartWorklistTemplateSelect, and LoanUpdate
- extranet access to the SmartWorklist, SmartWorklistTemplate, and Loan
With InheritedUser, the user need only have access to the SmartWorklistMember. As the application tier code instantiates related objects (SmartWorklist, SmartWorklistTemplate, Parent (Loan)), it does so with InheritedUser. The functional permission check (AbstractObject.VerifyPermission) will check to see if the user is inherited, and if so, bypass the need to have functional permissions. Similarly, the SqlPattern class will bypass adding extranet filters to underlying SQL statements, so the user need not have explicit extranet access to these objects.
This is a great convenience feature, but use cases can arise where using InheritedUser may not be desired. The Statement class includes an AllowInheritance attribute which defaults to true, but can be overridden. Thus, if there are statements which are 'powerful' in their execution and pose a potential security risk if executed as an inherited user, simply set the AllowInheritance attribute to false. |