...
- Client Application - Fedora
- Authorization Service - Google, etc..
- Resource Server - Fedora
OAuth 2.0 Authorization of Third-Party Applications
...
Principals used in ACLs
ModeShape has incorporated a pending pull request that implements part of the Access Control spec from JCR 2.0 (MODE-1920). Their implementation includes defined internal node properties and API for manipulating access control lists in the JCR repository. These are features of objects that are only accessed by clients through the AccessControlManager API.
...
- Use JCR API for attribute lookups
- Always store as much as possible in the repo itself. (A. Soroka)
- Less penalty for light authZ requests (i.e. use more attribute lookups based on Fedora object model)
- ??
Relevant Links
| Internal PDP (within ModeShape JVM) | External PDP (remote XACML service) |
|---|---|
Minimal administrative overhead through dependency injection, etc.. | Flexible, can be any XACML implementation |
| ModeShape cache will keep frequently used ACL metadata in memory. Removes the need for any additional cache. | Decent performance may require custom metadata caches. |
| No network overhead making connections or marshaling data. | Network latency, etc.. |
| Decision and policy cache invalidation may be based on events. | Cache invalidation requires wiring JCR or Fedora JMS specifics into the chosen XACML service. Cache invalidation would be asynchronous. |
Relevant Links
- JCR 2.0 Access Control Management
- MODE-1920 Pull Request (ACM)
- persistence of
- JCR 2.0 Access Control Management
- MODE-1920 Pull Request (ACM)
- persistence of access control lists that tie principals to a set of permissions
- ModeShape AuthorizationProvider interface
- Apache Shiro (framework of interest)
...
- Support a fedora admin container role - Reasonable performance is important when intercepting every request. In addition to performance optimizations, the PEP should allow a bypass method for requests considered pre-authorized for all repository actions by virtue of some container role.
- Repository admin should be able to update access policy on his/her items
- Content owner should be able to update access policy on his/her items
- Who is the content owner? Is this a feature of the RBAC profile (owner as role) or a general authorization feature? Or both? (I think owner is probably a role)
- If we define a Fedora owner property, then we have to restrict updates to it as well.
- And this should happen at the model, not at external APIs (A. Soroka)
- Support permission of specific actions, such as patch SPARQL update, as well as generic actions, like create, read, update and delete.
- Fedora API may not be granular enough in all cases, modifyDatastreams is in the API, but some of the datastreams might be restricted.
- Access should be controlled when an item is searched.
- Need specifics here. What metadata is protected on these items? How will we facilitate end-user authorization requests without providing some metadata?
- Access should be controlled when resource is requested directly
- Allow resources to be protected at the jcr node level
- Do we want policy language to reflect the Fedora API or the Fedora object model?
- The object model. The object model is the common set of notions for the entire repository. It is entirely plausible that parties will introduce new APIs, and we don't want to incur or inflict the cost of rewriting au th code. ( A. Soroka )
- Do we want policy language to reflect the Fedora API or the Fedora object model?
- Allow users to authenticate via Shibboleth, CAS, LDAP.
- Yes, but this should be a container concern. It would be great if LDAP user metadata could be packaged as SAML for the PEP.
- Agreed, but we need an extension point that allows us to gather more user details, other implementation-specific principals that might be granted roles/privs.
- Support for users granting permissions to applications via OAuth. (see below)
- Support for decision caching ( JBoss XACML decision cache )
...