Time/Place

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

Attendees

Agenda

  1. Collect stakeholder feedback on Sprint 1
  2. Review 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. 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. What Phase1 requirements must be addressed in Sprint2?
    1. Link header
    2. Remote ACLs
    3. ...
  4. Schedule second sprint
  5. 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

Facilitate Stakeholder Verification

  • Enable WebAC feature in fcrepo4-vagrant
  • Script the creation of resources and ACLs that correspond to stakeholder use cases
    • Stakeholders should provide additional use cases/scenarios as needed to help round out the verification

Sprint 2 Items to address

  1. Allow a specific agent to CREATE a resource, but not update it
  2. Currently, ACL resources are protected like other repository resources. Add special protection for ACL resources
  3. Implement "agent class" support:
    1. For agent classes that are found within the repository
    2. For agent classes that are found external to the repository (stretch, do stakeholders want this?)
    3. Allow repository admins to turn of "agent class" capability
  4. Implement "remote ACLs", if stakeholders view it as a priority
  5. Stretch goal: acl:include

Note: Since the WebAC "specification" does not have provisions for time-based authorization, the proposal is to move logic for policies such as leases or embargoes up into the application layer. Question for stakeholders, Is that reasonable?

 

 

  • No labels

16 Comments

  1. Stefano Cossu

    Regrets, I have a conflict right at that time.

     

  2. Stefano Cossu

    Note: Since the WebAC "specification" does not have provisions for time-based authorization, the proposal is to move logic for policies such as leases or embargoes up into the application layer. Question for stakeholders, Is that reasonable?

     

    I think time-based access is achievable with a mix of external scripting (e.g. Camel), application logic and standard WebAC – e.g. routinely checking for resources with an embargo date: if that date is expired, assign or remove a certain class to that resource which, by virtue of WebAC resource classes, would change its access policy. Is that an acceptable solution?

    1. Andrew Woods

      I think we are on the same page, Stefano Cossu. In your verification testing (fcrepo4-vagrant has Camel on it), if you would be interested in experimenting with such a pattern, that would be great.

      1. Stefano Cossu

        We don't use embargos but I will be glad to make up a scenario for them. For the Camel part I will defer to Unknown User (acoburn) if he is available to help since I am a complete jackass about it.

  3. Stefano Cossu

    Enable WebAC feature in fcrepo4-vagrant

    Thanks a lot. I was trying without success to deploy the  WAR file provided so far. I might wait till the Vagrant version is up.

  4. Stefano Cossu

     

    • Implement "agent class" support:
      1. For agent classes that are found within the repository
      2. For agent classes that are found external to the repository (stretch, do stakeholders want this?)
      3. Allow repository admins to turn of "agent class" capability

     

    I am not sure what the options above might entail. How is an agent class defined?

    In other words, if I have some headers coming e.g. from an LDAP principal provider telling me that the current user is in the "Prints and Drawings" department, as well as in the "Exhibition XYZ", "Invalid images" and "Secret cat videos" workgroups, how would I translate this membership information into agent classes?

    1. Andrew Woods

      To be clear, passing "group" information as request headers currently should work. If, however, you wanted to represent groups as "agent classes", you would create an RDF resource (group-x) that has any number of associated foaf:member resources. Your Authorization would define an acl:agentClass that points to group-x. 

      The diagram in the specification does a good job of depicting this:

      1. Stefano Cossu

        So you are confirming that an agent class is an RDF resource whose members are defined via the "foaf:member" predicate?

        In that case, are options 1 and 2 listed above about whether those lists should be provided by in-repo RDF resources and/or by external services providing a similar RDF output?

        1. Andrew Woods

          Exactly.

          1. Stefano Cossu

            Then I think that an external service would be very useful at least to query an external triplestore or Solr index for those in-repo resources, if that is considerably faster than searching in the repository itself.

            If the code is generic enough, an independent implementer could modify the service connection to retrieve that information from any API that provides a compatible option, e.g. by querying an LDAP server.

             

          2. Stefano Cossu

            My issue in general is that I have many hundreds of workgroups maintained in a custom application that serves as identity provider. Mirroring all those groups and their members in Fedora would be complex.

            The current SSO implementation (Shibboleth) that I am curently testing on provides membership info for the currently logged in user by querying the custom application. But if that information is not usable the way WebAC expects it, the alternative solution would be to associate the "agent class" to a service that queries the idp and outputs a RDF representation of the workgroup as an "agent class" and its members as foaf:member properties.

             

            1. Andrew Woods

              The two options you detail sound right, Stefano Cossu. Since you are using Shib, it may be simplest to pass the workgroup attributes in with the request as headers and not worry about agent classes.

              See: Principal Providers#HTTPHeaderPrincipalProvider

              1. Stefano Cossu

                So if I have these headers coming from Shibboleth:

                uid: scossu

                eduPersonPrimaryAffiliation: 112

                eduPersonAffiliation: 23,480,674

                (where 112 is the ID of my department and 23, 480, 674 other workgroups)

                and I include these headers in my HTTPHeaderPrincipalProvider configuration, how can I refer these in a webAC definiton, for example to make a resource accessible to all users in department 112 and another one to all users in workgroup 23?

                 

                1. Andrew Woods

                  You could have an authorizations such as:

                  <> a acl:Authorization ;
acl:accessTo <some-resource> ;
acl:mode acl:Read;
acl:agent "112" .

                  ...and

                  <> a acl:Authorization ;
acl:accessTo <some-other-resource> ;
acl:mode acl:Read;
acl:agent "23" .

                  1. Stefano Cossu

                    So in this case the departments and workgroups would not be distinguished from individual users. That seems semantically incorrect to me but I guess it obtains the same results. I will test this scenario.

                    1. Andrew Woods

                      Yes, all "agents" are currently treated equally.

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