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

Compare with Current View Page History

« Previous Version 20 Next »

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

Use Cases

  1. 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
  2. A user wishes to create multiple resources that all share access restrictions. The user is able to create a single access control list that is used by that group of resources. In addition, they do not have to explicitly link to the ACL from every resource; the appropriate ACL is inferred from the collection a resource is a member of, the class(es) is is an instance of, or other metadata associated with the resource.
    1. Given these multiple ways of inferring which ACLs apply to a given resource (via collection, class, or other metadata), there must be clear rules for determining the precedence of policies and for resolving conflicts between policies.
    2. In the interest of security, the absence of an applicable ACL should result in denial of Create, Update, and Delete requests (and possibly also Read requests?) to non-admin users, but should allow all CRUD operations to admin users.
  3. There is a collection that is by default restricted access. However, there are a selection of resources within that collection that are publicly available. These public resources are not necessarily grouped together in a single hierarchy within the collection.
  4. An unauthenticated user requests a publicly readable resource. The system retrieves and presents the resource to the user without any authentication challenge.
  5. An unauthenticated user requests a protected resource. The system presents them with an authentication challenge. The user successfully authenticates, and it is determined that they have read access to the requested resource. The system retrieves and presents the resource to the user.
  6. A resource can be related to tags. Each tag is contained in a tag category: Conservation, Imaging, Licensing, etc. For tags related to a certain resource:
    1. Imaging users can read, create and delete tags in Imaging category 
    2. Imaging users can read tags in Conservation category
    3. Conservation users can read, create and delete tags in Conservation and Imaging categories
    • Note: F4 does not have "tags" per se. Are you envisioning a "tag" as a resource? or a property?
    • See comment below
  7. An authorized user must be able to change which ACL applies to a given resource or group of resources without moving those resources.
  8. An authorized user must be able to edit an ACL in place in order to update the policy that applies to all resources governed by that ACL.
  9. It should be possible to create an ACL that changes over time without user intervention (e.g. an embargo policy).

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? Extensions in the current version include inheritance (seems very useful) and regex matching (which 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 the latter are admittedly going to be rare, it would seem better not to be opinionated here if public write is what an implementer 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?
    3. Or should our implementation support both?
  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 made possible by LDP and 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 says its items are publicly readable, but certain items in that collection have a status of incomplete (and there exists another rule that incomplete items are not to be publicly available), then the more restrictive policy would seem to be the one that ought to win out. This example is chosen for the sake of argument even though it seems as though it ought to be possible to devise a single ACL policy to handle the combination of collection and status rules.
  6. F4 MUST provide a way for external services such as Solr to enforce the authorization rules defined in the repository.
    1. Would one method of achieving this be to create separate solr cores for public users vs. admin users and publish only the public resources to the former and everything to the latter, or does the use case dictate more granular distinctions?

Authentication Considerations

Fedora 4 always assumes that any incoming request has always been authenticated by the container (or other layers above it in the stack). Therefore, these considerations may not be central to the design of a new authorization delegate; however, I (peichman) do believe they represent an important part of setting up a Fedora instance (beyond just the core servlet code) and should be addressed in some form.

  1. Authorization logic should be capable of evaluating four pieces of information about a given request: (1) Origin (IP address), (2) identity of requester (or anonymous if not authenticated), (3) the resource being requested, and (4) the method or action of the request (read/write, GET/POST, etc.).
  2. After evaluating the WebACL policies that apply to the requested resource against the four pieces of information listed above, the application should return one of three responses: (1) fulfill the request, (2) prompt the user to authenticate, or (3) deny the request.

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.