Attendees
- Unknown User (acoburn)
- Peter Eichman
- Mohamed Mohideen Abdul Rasheed
- Jared Whiklo
- David Wilcox
- Andrew Woods
General
- Indicates who took minutes -
- Call-in: Google-hangout at:
Meetings
08/24
08/25
- Yesterday:
- Jared
- Edited design doc based on what we're working on
- Jared
- Aaron
- Pulled together stuff for integration tests
- Will add pull request
- Mohamed
- Created basic docs for WebAC auth delegate
- User focused
- Added a flow diagram
- Will iterate on this as needed
- How much of this should be in the README file vs. the DuraSpace wiki?
- The README file is great for developers
- Wiki docs are more production-oriented. For dev-ops, sys-admins, users
- Peter
- Created basic no-op implementation
- Need to start building out implementation
- Class-based and access-to
- How it applies to a user vs. a group
- Create a class to read and parse an ACL: Mohamed
- Access-to-class: Given an ACL, a class of resources, a resource, a username, and a set of roles:
- Does the ACL apply to the resource?
- What modes does the user have access to?
- ACLs are stored in a configurable location
- Access-to-class: Given an ACL, a class of resources, a resource, a username, and a set of roles:
- Create an analogous class to handle access-to: Peter
- Given an ACL and a username and a set of roles, what modes does this user have access to?
- Wire everything together and write tests: Aaron
- First step: build interfaces
08/26
- Informal process for PRs
- Two thumbs-up from sprint members will approve a PR
- URI constants PR
- No issues to discuss
- AccessToClass Handler Interface PR
- Constant should not be mutable
- AccessTo handler
- Peter still needs to implement
- Example: We have an ACL that points to a resource in Fedora
- How do we determine if the ACL applies to a resource, and what gets returned?
- Not the ACL itself but a link header that points to the ACL
- In the case of multiple ACLs, return a link to the most permissive ACL
- How do we determine if the ACL applies to a resource, and what gets returned?
- Do we need an RDF relationship where the resource is the subject and its ACL is the object?
- We do not - the triple will have the ACL as the subject and the protected resource as the object
- Are ACLs first-class resources with associated triples, or resources with child hash resources that themselves have associated triples
- Each ACL will be a first class resource with associated triples
- Authorization is an rdf:type
- An ACL resource has an rdf:type of authorization
- Global vs. collection-based access-to-class ACLs
- If accessToClass ACLs are global, all access-to-class assertions would need to be in a single ACL
- Different rules for different collections would not be possible
- We could get around this by keeping global accessToClass rules at the root node
- In this way they could be overridden by ACLs at lower level collections
- If accessToClass ACLs are global, all access-to-class assertions would need to be in a single ACL
- Proposal: Associating ACLs with resources
- Any resource can have a “hasACL” property
- If a resource has such a property it is used, if not we continue walking up the tree until a relevant ACL is found
- Proposal: ACLs will be containers with child authorization resources
- ACL container will not contain any assertions about authorization. It is an aggregation of its children
- The child authorization resources contain assertions about authorization
- We traverse the children to determine whether or not a user has access to a resource
08/27
08/28
- Updates
- Jared
- Yesterday
- PR review
- Squashing commits
- Today
- Refactoring
- Yesterday
- Mohamed
- Yesterday
- Minor changes to authorization interfaces
- PR review
- Today
- Implementing authorization handler
- Yesterday
- Peter
- Yesterday
- PR review
- Discussion
- Today
- Refactoring
- Working on other things that come up in discussion
- Yesterday
- Jared
- Much of the week has been spent getting everyone on the same page and developing a shared understanding on the implementation
- Things that need to happen:
- Refactoring
- Initial tie-in point:https://github.com/fcrepo4/fcrepo4/blob/master/fcrepo-auth-common/src/main/java/org/fcrepo/auth/common/ServletContainerAuthenticationProvider.java
- Entry point for all the work we’re doing
- Should use this class rather than rewriting it
- Refactor line 50 and 55
- Review implementation of principal providers
- https://github.com/fcrepo4/fcrepo4/blob/master/fcrepo-auth-common/src/main/java/org/fcrepo/auth/common/FedoraUserSecurityContext.java
- Probably can only use this class for inspiration
- Review and recommend refactoring if necessary:
- https://github.com/fcrepo4/fcrepo-module-auth-rbacl/blob/master/fcrepo-auth-roles-common/src/main/java/org/fcrepo/auth/roles/common/AbstractRolesAuthorizationDelegate.java
- https://github.com/fcrepo4/fcrepo-module-auth-rbacl/blob/master/fcrepo-auth-roles-common/src/main/java/org/fcrepo/auth/roles/common/AccessRolesProvider.java
- Initial tie-in point:https://github.com/fcrepo4/fcrepo4/blob/master/fcrepo-auth-common/src/main/java/org/fcrepo/auth/common/ServletContainerAuthenticationProvider.java
- Other tasks
- fcrepo-webapp-plus
- Need to build in a profile for WebAC configuration
- Integration tests
- Leverage existing tests where possible
- Put together a suite of integration tests in advance of an implementation
- Documentation
- Establish 4 scenarios that involve protecting resources with WebAC
- Document SPARQL-Update recipes for addressing these scenarios
- fcrepo-webapp-plus
- Refactoring
08/31
- Peter
- Friday
- Updated ServletContainerAutheticationProvider class
- Change concept of “everyone” to “foam:agent"
- Some changes to role based authentication and XACML modules will be required as they expect “everyone"
- Investigated integration testing suite
- See what we can reuse for WebAC testing
- Updated ServletContainerAutheticationProvider class
- Friday
- Mohamed
- Friday
- Created FedoraWebACUserSecurityContext class
- Today
- Update WebAppPlus
- Moving WebAC user security context out of main codebase
- Friday
- Jared
- Friday
- AbstractRolesAuthorizationDelegate
- We could extend this class, or implement FedoraAuthorizationDelegate directly
- Extending this class is probably the best way to go
- We could extend this class, or implement FedoraAuthorizationDelegate directly
- AccessRolesProvider
- Does not use ldp:contains to traverse the repository, so not useful for WebAC implementation
- Added scenarios to WebAC documentation
- AbstractRolesAuthorizationDelegate
- Today
- Interface work with AccessRolesProvider
- Creating another scenario for the documentation
- Friday
09/01
09/02
09/03
- Fedora Tech Meeting