...
- Client Application - Fedora
- Authorization Service - Google, etc..
- Resource Server - Fedora
OAuth 2.
...
From the OAuth 1.0 specification:
...
0 Application Authorization
From the OAuth 2.0 specification:
...
Applications can be authenticated by means of token credentials generated through the OAuth 2.0 framework. Subject to the practical limitations explored below, Fedora will be designed such that application authorization happens can happen within the OAuth workflow. While OAuth is supported and encouraged, applications can still authenticate via use container-level "user authentication". authentication, obtaining a container role and matching access. Therefore OAuth support is not required of all Fedora client applications.
...
- In servlet container authentication, forwarding with require the container role of fedoraProxy.
- In OAuth token authentication, the token must include the scope forwardCredentials.
Establishing JCR Sessions
All requests to the JCR repository that underlies Fedora come through a JCR Session. The JCR Session results from JCR authentication and contain security context that allows the repository to make the most granular Fedora authorization decisions downstream. JCR sessions are tied to every Fedora REST request by means of an InjectedSession annotation on resources. This annotation will bring in a JCR Session from a SessionProvider that in turn gets the Session from a SessionFactory. During Fedora transactions a JCR Session is saved with the transaction. Sessions in transactions will remain open until the transaction is closed or the maximum time between requests is reached.
JCR authentication is based on ServletCredentials that are passed through from the REST endpoint. The place to start looking at this is the SessionFactory, which retrieves the transaction session or formulates a repository login attempt from the servlet request. Repository logins are based on an extensible credentials object. In ModeShape logins may be implemented by many implementations of an AuthenticationProvider interface. Fedora includes an ServletAuthenticationProvider that checks requests for a Fedora user role of either fedoraUser or fedoraAdmin before permitting Session creation.
| Info | ||
|---|---|---|
| ||
The AuthenticationProvider is a ModeShape interface that allows implementations to authenticate JCR sessions on the basis of custom credentials. Implementations may create a custom security context here that implements highly granular JCR authorization. This is really a ModeShape extension point used internally by Fedora. For the analogous Fedora extension point, see Policy Enforcement Point (PEP). See https://docs.jboss.org/author/display/MODE/Custom+authentication+providers |
| Info | ||
|---|---|---|
| ||
Fedora ships with a Authentication Provider that checks for proper Fedora user roles before session creation. It creates a security context that delegates ModeShape authorization decisions to the Fedora Policy Enforcement Point (PEP). |
| Info | ||
|---|---|---|
| ||
Fedora ships with an authentication provider that verifies OAuth token credentials and creates a special OAuth security context for new sessions. This provider will first enforce OAuth token scope and then delegate further authorization decisions to the Fedora Policy Enforcement Point, as appropriate for the token. |
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 (for now, simply a JCR Session) and may all fail together due to a permission or validity check.
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?)
Fedora Admin Authorization Module
This is a very simple, servlet-based authorization system. Its authentication provider will only create sessions for servlet requests that have the fedoraAdmin container role. It authorizes admins users to perform all actions.
XACML Fedora User Authorization Module
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 request information into a authorization request that is passed to a policy decision point (PDP) according to the XACML standard.
- This authorization provider will 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.
- ModeShape Question: How best to store policies within the repository? (normal nodes/properties or possibly behind the AccessManager API)
Option: Internal PDP vs. External
- 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)
| 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 access control lists that tie principals to a set of permissions
- ModeShape AuthorizationProvider interface
- Apache Shiro (framework of interest)
Possible Components
- JBoss XACML Engine
- JBoss SAML PDP endpoint (takes SAML payload + XACML request over SOAP)
- 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
Requirements
- 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 )
- forward credentials.
XACML Authorization Extension: Content Roles and Policies
...
- 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...)
- Is this something that XACML can do for us, or something we would have to rig up? - Greg Jansen
- Set operations between roles? (role D can do what role A can do, except for what roles B or C can do)
- see above
- Provide examples of custom attributes being used in policies (a publication flag or embargo date, for instance)
Authorization for Other REST API
...
This approach intercepts JAX-RS-supported HTTP requests and provides some form of policy enforcement around the API operation.
...
Endpoints
These endpoints in the REST API will require the fedoraAdmin container role or the fedora administrator OAuth token scope:
TBD
Code Repository
The Fedora AuthN/AuthZ modules are under construction. For now this is some prototype code in development here: