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

Compare with Current View Page History

« Previous Version 6 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
  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
  4. F4 MUST allow authorization policies to apply to a group of resources
  5. F4 MUST honor the most permissive authorization policy when multiple policies apply to a 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