...

Fedora Content Roles

This is an optional approach to Fedora authorization in which users (security principals) are assigned named content roles on Fedora objects. The roles assigned in the tree of Fedora objects can be used in authorization mechanisms to confer broad access privileges. These authorization mechanisms (implementations of the AuthorizationProvider interface) can easily retrieve content roles specific to a Fedora object or JCR path. Fedora defines some useful conventions for content roles:

• 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 added 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.

Fedora provides a reference set of XACML policies formulated around content roles. These policies are written per role, so you can add whichever role/policy combinations you need to your repository.

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. You can also assign content roles to the Everyone principal, which is present in every Fedora security context.

ModeShape-Based Authorization Modules

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 and may all fail together due to a permission 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.

...

A custom SecurityContext class can implement the existing AuthorizationProvider or AdvancedAuthorizationProvider interfaces to implement specialized security checks through the hasPermission method. 

• Best for enforcement policies based on Fedora structures, i.e. policies govern CRUD on the nodes/properties of the Fedora object
• It's the JCR way, secures the JCR API as well
• More security checks, but less complexity (consider SPARQL update, for instance)
• Cannot block the whole Fedora API method before execution (but we have transactions?)

MODE-1920 AccessManager API

Principal Discovery

Principals used in ACLs

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.

• ModeShape Question: How best to store roles and policies within the repository? (normal nodes/properties or behind the AccessManager API)

XACML PEP AuthorizationProvider

XACML Authorization Module

• This authorization provider will This provider would delegate authorization decisions to a XACML PDP.
• Policies might be stored in the repository tree (see JCR 2.0 16.3 and JBossLDAPPolicyLocator as an example)
• ?? Standard and customized XACML attribute mappings could be stored in the repository. (JCR query, data type, attribute ID)
  
  • Write an "attribute finder" based on relative JCR XPath.
• Roles could be assigned to principals on Fedora object nodes. (Probably should involve an upstream ModeShape change to AccessManager.)
• Best implemented against MODE-1920 (a pending pull request for 3.4)
  
  • Gives us a standard place to store ACLs on nodes (limited to user => permission sets)
• Best for enforcement policies based on Fedora structures, i.e. policies govern CRUD on the nodes/properties of the Fedora object
• More security checks, but less complexity (consider SPARQL update, for instance)
• It's the JCR way, secures the JCR API as well
• Cannot block the whole Fedora API method before execution (but we have transactions?ModeShape Question: How best to store policies within the repository? (normal nodes/properties or possibly behind the AccessManager API)

Option: Internal PDP vs. External

...

• JBoss XACML Engine
• JBoss SAML PDP endpoint (takes SAML payload + XACML request over SOAP)
• PEP Interceptor for Fedora REST API (intercepts JAX-RS)
• Filesystem Connector (configures JCR access to live policies folder)
• Security attributes source (typically configured at container level, e.g. Shibboleth)
  • Can we contain this variability using Principals? Installers configure or write their own serializable Principal objects, based on their attribute source?
• Some useful reference implementations of Fedora authorization policy

...

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

XACML Authorization Extension: Content Roles and Policies

This is an optional approach to Fedora authorization in which users (security principals) are assigned named content roles on Fedora objects. The roles assigned in the tree of Fedora objects can be used in authorization mechanisms to confer broad access privileges. These authorization mechanisms (implementations of the AuthorizationProvider interface) can easily retrieve content roles specific to a Fedora object or JCR path. Fedora defines some useful conventions for content roles:

• 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 added 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.

Fedora provides a reference set of XACML policies formulated around content roles. These policies are written per role, so you can add whichever role/policy combinations you need to your repository.

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. You can also assign content roles to the Everyone principal, which is present in every Fedora security context.

Reference Profile: Role-Based Access Control (RBAC)

...

• user principals (user, group)
• roles assigned to principals (for RBAC, possibly stored in Mode's AccessControlManager ACL)
  
  • coming from the object above the datastream or higher up
• Just enforcing who can modify datastreams means determining node type and checking for that specific permission with respect to the role.
• Restricting by datastream name or other metadata?

REST API-Based Authorization

These approached intercept JAX-RS requests and provide some form of policy enforcement around the API operation.