ESciDoc Institutional visibility

Requirement:

Access to content of a component should be restricted to users that may

• retrieve the item

and

• 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.

Mih 14:48, 2 September 2008 (UTC) Question: How can we evaluate the user group or the ip-address of the user if the framework does not know about it?

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.

--Natasa 10:50, 29 August 2008 (UTC)

• for files / locators: object policies should be certainly evaluated when retrieving the content
• we should have information provided with component-level properties/metadata on component-level visibility. If the visibility is a "policy" then in addition id of the policy that needs to be evaluated (i.e. this information can be provided in retrieveItem and retrieveComponent methods )

Mih 11:36, 1 September 2008 (UTC)

• • We do not really have a visibility for the content that we could set to any value. We will have policies for 'private' access, 'public' access and 'ou-access'. Later on there will be more policies like eg 'user group'. These policies can get attached to the object and these policies will get evaluated when calling certain methods (retrieve-content). The names of the methods where the policy has to get evaluated is defined within the policy. This means that we can attach any policies to any object. We should not have a reference to the policies in the object-xml. Maybe later on we want to have an object-policy that gets evaluated when calling retrieveItem or retrieveProperties. If someone wants to know the policies that are attached to a specific object, there will be a new handler-method in the AA-Component that can deliver all object-policies for one object.

• • Invent new Handler-Methods into the AA-Component that enable creating, updating, deleting and retrieval of ObjectPolicies + Attributes for one Object.

in addition evaluating the policy? --Natasa 10:50, 29 August 2008 (UTC)

• 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.

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

to clarify this better: a role policy for context is evaluated on item level, in addition, each item may have object-level policy for each file. So users do not have to have different object-level policies for items+object-level policies for files. The case is usually, role-level policy on ctx+object-level policy on file (optional, in case visibility is "policy")

• Element visibility in component-properties is not used anymore

element visibility may be used as a short-cut to tell: it's public, private or a policy should be evaluated (so that system does not go always to the XACML policy store)--Natasa 10:50, 29 August 2008 (UTC)

Mih 11:36, 1 September 2008 (UTC) public and private also will be policies. Instead of parsing the item-xml to retrieve the content of the element visibility, we now have to go to the database and retrieve the policies for the object and then evaluate them. Database-Access hopefully will not be less performant than parsing the xml.

Examples of fulltext visibility at present on eDoc

• Metadaten ¨offentlich/Volltext ¨offentlich ("Public")
• Metadaten ¨offentlich/Volltext für die MPG ("MPG wide access")
• Metadaten ¨offentlich/Volltext für das MPI ("Institute level access": Damit schränkt man den Zugriff auf das gesamte MPI ein. Jeder Nutzer, der entweder für das MPI registriert ist – Erkennung ¨uber Login – oder sich über einen Computer des Instituts einloggt – Erkennung über IP-Adresse – hat Zugriff)

• Metadaten "offentlich/Volltext" für einen internen Nutzerkreis ("internal access":Damit schr¨ankt man den Zugriff auf einen internen Nutzerkreis ein: local eDoc Manager, Collection Authority, Collection Moderator und Depositor/Owner des Dokuments) • Metadaten "offentlich/Volltext nur für privilegierte Nutzer ("Privileged users access": Damit schränkt man den Zugriff auf eine privilegierte Nutzergruppe ein: local eDoc Manager, Collection Authority, Collection Moderator, Nutzer mit Privileged View für diese Collection und Depositor/Owner des Dokuments)

Coordinated Universal Time

eXtensible Access Control Markup Language

Electronic Documentation

Max-Planck-Gesellschaft

Max-Planck-Institut

Internet Protocol