ESciDoc Institutional visibility

Requirement: Access to content of a component should be restricted to users that may 1. retrieve the item

  and

2. belong to an organizational Unit or child-org-unit of a list of Org units that is defined for the component.

The requirement should be extendable so that it is possible to restrict the access also to certain user groups or certain ip-ranges.

Proposal: -Invent possibility to attach XACML-Policies to Objects + to attach Attributes to these ObjectPolicies (eg a list of OrgUnit-Ids). -Dont store the XACML-Policies + Attributes within the Object but outside in a database. ->One Database-Table that stores all possible ObjectPolicies (eg OrgUnitContentRestrictionPolicy) ->One Database-Table that brings together the object and the policy. Fields: objectId policyId (reference to Policies-DB-Table) list of Attributes -Mark certain Methods (eg retrieveContent) as Method where ObjectPolicies have to get evaluated. -Invent new Handler-Methods into the AA-Component that enable creating, updating, deleting and retrieval of ObjectPolicies + Attributes for one Object. -Evaluate these Policies in addition to the RolePolicies the user has.

If the RolePolicies return a Permit and the ObjectPolicies return a Permit, 
then the user is allowed to access the Method (eg retrieveContent).
Vice-Versa: If one of the Policies returns a Deny, then the user is not allowed to access the Method.

-keep element visibility in component-properties.

Link the attached Policy to element-value public, private or restricted.
This is only done that the user can see what policies are attached. The element is not evaluated. 
visibility private and public are also policies that are attached to the object. 
This means that the visibility-element cannot be set directly but only by setting the Object-policies via the new HandlerMethod.

-If no object-policy is attached to the object, only the role-policies are evaluated.

eXtensible Access Control Markup Language