...

Fedora 4 will intercept JCR operations in order to enforce policies that are based on the Fedora object model and other node characteristics. While a single Fedora API call may span several JCR operations, these will be joined by a JCR transaction (for now, simply a JCR Session) and may all fail together due to a permission or validity check.

Policies will be stored in the repository attached to or in some (likely hierarchical) relationship to the nodes that they govern. Many nodes may attach the same named policy.

...

ModeShape has 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.

...

This is a very simple, servlet-based authorization system. It's Its authentication provider will only create sessions for servlet requests that have the fedoraAdmin container role. It authorizes admins users to perform all actions.

...

This module creates sessions only for requests bearing a fedoraUser container role. It is useful in cases where Fedora is responding directly to container authenticated end users. This module compiles requests request information into a authorization request that is passed to a policy decision point (PDP) according to the XACML standard.

...

• 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)
• ??

...

• 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 )
• 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.
• Support for users granting permissions to applications via OAuth. (see below)
• Support for decision caching ( JBoss XACML decision cache )

...

• Owner - This is a read/write role that also allows the user to assign roles to others.
• Content roles are stored on a Fedora object mixin node - authorization mechanism must enforce edit privileges on this node.
• Content roles are inherited from higher up in the tree of Fedora objects.
• New roles may be assigned lower in the tree of Fedora objects.
• Role inheritance can be blocked at any point in the tree.
• Content roles have no effect on the privileges granted to user roles (originating in container auth) or conferred by other means.
• Roles can be assigned to any security principal that is available in the Fedora security context.
  
  • This can include things like a user, a named IP range, LDAP group or organizational affiliation.
  • Can be based on Shibboleth supplied x.520 headers
  • Are there useful CAS attributes other than username? Do CAS implementations use LDAP, for instance?
  • You can also assign roles to the Everyone principal, present in every Fedora security context.
    • Is Everyone anonymous? Or is there Everyone (that we know), and then Everyone (that we know) + Anyone (A. Soroka)
• A query A query can retrieve all content roles assigned to an object or a principal.

...

• Do we support policies with additive permissions? (role B policy has all permissions of role A policy, plus...)
• Subtractive permissions (role B policy has all permissions of role A policy, minus...)
• Set operations between roles? (role D can do what role A can do, except for what roles B or C can do)
• Provide examples of custom attributes being used in policies (a publication flag or embargo date, for instance)

REST API-Based Authorization

These approached intercept This approach intercepts JAX-RS-supported HTTP requests and provide some form of policy enforcement around the API operation.

...