Time/Place

  • Time: 3:00pm Eastern Daylight Time US (UTC-4)
  • Call-in: 

Attendees

Agenda

  1. Review WebAC fundamentals
  2. Establish minimum Phase1 scope/use-cases
    1. Allow admin agent to always have full access to resources and ACLs
    2. Allow admin agent to CRUD ACLs
    3. Allow admin agent to assign ACLs to resources
    4. Allow a specific agent to READ a resource
    5. Allow a specific agent to READ and WRITE a resource
    6. Allow a specific agent to CREATE a resource, but not update it
    7. Allow a specific agent to assign an ACL
    8. START HERE — Allow a class of agent to do the above (d - g)
    9. Allow a specific agent to do the above over a class of resources (d - g)
    10. Allow a class of agent to do the above over a class of resources (d - g)
    11. When access is denied return a 403 and a body (or link header) with cause
  3. Reconfirm commitments
  4. Schedule initial two sprints
  5. Address questions (can also happen offline)
    1. ACL resource is its own ACL?
    2. What is the algorithm for finding an ACL on a resource?
      1. if is ACL (rdf:type Authorization), use itself
      2. if incoming reference from ACL, use it
      3. else traverse up ldp:contains or pcdm:hasMember or custom? relationships
    3. How should conflicting policies be handled? e.g...
      1. (userA=WRITE, public=READ) => result of WRITE request from userA?
      2. (userA=READ, groupB=WRITE) => result of WRITE request from userA, assuming userA is member of groupB?
  6. Discuss Phase2 scope/use-cases
    1. Allow a request from a specific I.P. address (or range?) to do the above for a resource and a class of resources (2.d - g)
    2. Enforce authorization policy on a resource (or class of resources) based on that resource's association to a licenses (or tag)
    3. Enforce datetime sensitive authorization polices (i.e. embargos / leases)
    4. Allow authorization decisions based on nested ACLs (i.e. acl:include)
    5. Demonstrate pattern for enforcing the same authorization decisions as found in the repository in the context of Solr queries

Related Documents

Minutes

  • Agent class
    • What makes sense for phase 1?
    • In spec, class of agent is a URL that points to a listing of user IDs
      • ACL has an agent class that points to this list of user IDs
      • Can this be any arbitrary URL that resolves to a list of users?
        • Must have a number of FOAF members (i.e. it returns a graph)
      • Lots of upsides to following the spec, but many existing services may not be able to use this functionality without some kind of middleware to translate the output to an RDF graph with appropriate properties
        • This could be a maintenance issue. We would probably need an API capable of translating between a variety of services
      • In order to constrain the scope of phase 1, this could be a stretch goal
        • If we go this route, we probably won’t support any notion of groups until we implement this as per the spec
        • It would not be good to implement a fall-back if we are only going to rip it out when we implement the agent class functionality as people may write code around it and come to rely on it
    • Could fall back to group notion
      • If a user belongs to a particular group, the ACL will permit access
  • Class of resource
    • An agent can have permission to act on a class of resources
    • Any agent with the ability to update a particular resource will have the right to add that resource to a class or remove it from a class
    • This may need some clarification and further discussion but we can likely implement as per spec without significant risk
  • Providing information to users
    • The spec recommends providing information to users when they are denied access that explains why they were denied and how they can gain access
    • We already have some examples of this in the existing authorization delegates
      • We can just return a 403
  • Developer commitments
    • Peter, Mohamed, Jared, Aaron (?)
  • Stakeholders
    • Josh, Stefano, Nick
  • Sprints
    • Aug. 24
    • Sept. 28
  • Protecting ACLs themselves
    • ACL resources are their own ACL (e.g. they do not reference another ACL for access control)
  • Algorithm for finding ACLs on a resource
    • If resource isn’t an ACL or does not have an inbound reference from an ACL, traverse up the graph to find an ACL
      • In this case do we use the first ACL found or continue traversing until all relevant ACLs are found?
        • Continuing to traverse after the first ACL has performance implications
        • There is an acl:include extension that would allow admins to explicitly include more than one ACL
    • Proposal: Stop at first ACL in phase 1, support acl:includes in phase 2
  • How to resolve conflicts
    • For a given user, first check to see if there is an ACL that references that user specifically. If there is, stop. If not, go to the policy that references the group the user belongs to
      • If the user has no specific policy and the user belongs to two groups with different policies, the most permissive combination of permissions should apply
  • No labels

6 Comments

  1. Unknown User (westgardja)

    Unfortunately I won't be able to make this meeting time next week, but Peter should be able to represent our interests in this effort.  The outstanding questions for me that we didn't get to in today's meeting are largely captured in point 5 on the agenda, but I'll just add a few reactions and additional questions:

    1. Since ACLs are going to be Fedora resources in their own right, the question arises how to manage access to the ACLs themselves. Having the ACL be a special class of resource for which it is its own ACL (see point 5a above) seems like an elegant solution that should work for us.
    2. In addition to the question of the algorithm for finding the applicable ACL, I would like us to decide whether or not it should be possible to have more than one ACL apply to a single resource.  In the interest of simplifying the implementation, I would like to propose that only one ACL can apply.  Thus, Fedora might prevent the creation of a property with the predicate acl:acl on a resource that already has such a property.  This would also allow Fedora to stop looking once it finds an applicable ACL (i.e. if there is an ACL attached to a resource, Fedora needn't go searching up the LDP containment tree).
    3. Furthermore, I think we also need an algorithm for determining which of the individual access controls (i.e. the various assertions made inside any one ACL) apply where more than one might be applicable to a given request.  In this case I would propose that the bias should be in favor of allowing access. That is, Fedora is going to read the entire ACL, and if according to any of the assertions contained therein, the request should be permissible, then Fedora should fulfill the request. I think this is perhaps what was intended by requirement #5 on the design page, that the more permissive rule should apply in cases of a conflict. If that is correct, I agree.

    1. Andrew Woods

      Thanks for these comments, Joshua Westgard. Particularly for Phase1, and potentially subsequent Phases, I agree with all of your points:

      1. ACL acts as its own ACL
      2. Only one ACL applies, the first one found based on a yet-to-be-defined discovery algorithm (future Phases may decide to also use "acl:include" for bringing in other policies)
      3. If more than one assertion applies in an ACL, enforce the one that allows the most privilege

  2. Stefano Cossu

    • Lots of upsides to following the spec, but many existing services may not be able to use this functionality without some kind of middleware to translate the output to an RDF graph with appropriate properties
      • This could be a maintenance issue. We would probably need an API capable of translating between a variety of services

    Am I missing something? I am not sure about what the exact concern is here. Should the authorization delegate be concerned at all with a middleware or an API? In some cases an API might not be even needed, e.g. if user class URIs resolve to static graphs stored as files in Fedora or elsewhere and managed by a third party application. 

    If a tie with directory services or similar is needed, a middleware is indeed necessary to translate the membership information provided by these services into the RDF format expected by the auth delegate. Should this not be up to the implementer to build (possibly as a community project)?

    1. Andrew Woods

      I think the concern is as simple as recognizing that existing institutional environments rely on a variety of group-management systems (LDAP, Grouper, etc). These systems likely do not expose a REST-API, more less one that responds with an RDF graph that includes membership triples.

      By implementing "agentClass" per the spec, we need to account for the fact that middleware will likely need to be created to translate interaction with these group-management systems to a RESTful RDF model.

      1. Stefano Cossu

        I agree; but it still seems worth while to me to implement agent classes as per specs and leaving it up to the implementer to build a middleware suitable for their institution, than not implementing any agent classes at all, as suggested in the discussion. 

        In a simple scenario agent classes could be even set up in static graphs stored as Fedora resources without relying on any external API or custom middleware. 

        1. Andrew Woods

          I think we landed on the implementation of agentClass being a stretch goal.

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