ESciDoc Institutional visibility
Revision as of 15:37, 3 September 2008 by Inga (talk | contribs) (→Examples of fulltext visibility at present on eDoc)
Requirement:[edit]
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.
Mih 06:42, 3 September 2008 (UTC) Question: So System-Administrator will not be able to retrieve content if he is not in the proper orgUnit?
- Is there an answer to that question? If there is really an AND between "retrieve the item" and "belong to an OU ..." it has a huge impact to policy evaluation. The problem is the "visibility policy" is an additional one that is evaluated independent from the policies bound to a role. As I understand, till now access is granted if no "role policy" denies access. So, if the only policy bound to the role system-admin is "allow all" then the system admin is allowed to access everything (also binary content). With this "visibility role" we introduce an additional policy that is now evaluated for system admin too and denies access to binary content in case system admin is not member of a named OU. Frank 15:36, 3 September 2008 (UTC)
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:[edit]
- 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
- Fields:
- Dont store the XACML-Policies + Attributes within the Object but outside in a database.
- 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[edit]
- Metadaten öffentlich + Volltext öffentlich ("Public")
- Metadaten öffentlich + Volltext für die MPG ("MPG wide access")
- Metadaten öffentlich + 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 über Login – oder sich über einen Computer des Instituts einloggt – Erkennung über IP-Adresse – hat Zugriff)
- Metadaten öffentlich + Volltext für einen internen Nutzerkreis ("internal access": Damit schränkt man den Zugriff auf einen internen Nutzerkreis ein: local eDoc Manager, Collection Authority, Collection Moderator und Depositor/Owner des Dokuments)
- Metadaten öffentlich + 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)