You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 7 Next »

This page will be used to design a WebAccessControl Authorization Delegate.

Use Cases

  1. Authorization enforced within F4 must also be enforceable by external services, such as Solr.
  2. As a user from the Registrar office creates an Asset with a loan agreement document, the user assigns a property to the asset indicating that the asset is restricted to the Registrar staff, the user (a member of the Registrar group) should not be locked out of viewing/editing the resource

Proposed Requirements

  1. F4 MUST allow assertions about authorization to be modeled in RDF in accordance with the WebAccessControl specification
    1. Given that the W3C spec is still at a very early stage (still a wiki, not even a formal draft yet), it will be necessary for us to unpack and clarify a number of points in the specification and decide which of the proposed elements we will follow.
    2. Should we adopt optional extensions, including inheritance (seems very useful) and regex (seems like it could be difficult to implement)
  2. F4 MUST be able to enforce authorization based on WebAC when a resource is requested via the REST-API
  3. F4 resources that are open for public read should not challenge the client to authenticate
    1. What if a resource has no ACL? Should there be a default behavior? (for example allow all to admin user; deny all to non-admin?)
    2. This requirement specifies public *read*. Do we also want to allow a public write? While use cases for this are admittedly going to be rare, it would seem better to not be opinionated here if that's what an implementor wants.
  4. F4 MUST allow authorization policies to apply to a group of resources
    1. Do these groupings of resources relate at all to the underlying JCR tree?
    2. Or are these groups created at the content modeling layer by the rules of the LDP spec for containers?
  5. F4 MUST honor the most permissive authorization policy when multiple policies apply to a request
    1. What are the conditions under which multiple policies would apply?  Two conflicting ACLs attached to a particular resource? or a conflicting ACL attached to a resource somewhere higher up the tree, with the conflict brought about through inheritance?
    2. In order to create an implementation that will allow complex content modeling such as that embodied by PCDM, it seems as though some concept of inheritance of access controls would be very useful, but the WebAC spec is very thin on this point at the moment.  Under what rules would inheritance apply?  If no ACL is found on a resource, should one be sought on parent resources? When does this seeking stop (at the first ACL found?).
    3. With respect to the reconciliation of conflicting policies, could we unpack the idea that the more permissive policy always wins?  I would have thought the opposite is more intuitive.  For example if a collection is governed by a rule that items are publicly readable, but certain items in that collection have a status of incomplete (and there exists a rule that incomplete items are not publicly available), then it is the more restrictive policy that would seem ought to win out in the conflict.  Admittedly, it seems as though a single ACL policy could be devised to handle the combination of collection and status rules.

Open Questions

  1. What are the exact behaviors associated with the following permissions?
    1. READ
    2. WRITE
    3. Append
    4. Control
  2. Is there anything currently implemented within the Hydra WebAC implementation that strays from direct compatibility with the WebAC standard? In other words, are there currently barriers to the goal of cross-application compatibility?

Role Commitments

Development

Stakeholder

Related Documents

  • No labels

All content on the LYRASIS Wiki is licensed under the CC BY (Attribution) license, unless otherwise noted.