| F4 alpha 2 |
|---|
| Table of Contents |
|---|
Overview
| Excerpt |
|---|
| Fedora 4 authorization is designed to be fine grained, while at the same time manageable by administrators and end users. Authentication is tied to managed by the servlet container or OAuth tokensexternally, but authorization mechanisms are open to extension and many reference implementations are included. Roles-based access control is an included feature that makes permissions more manageable and at the same time easier for external applications to retrieve, index and enforce. Finer grained security checks have no impact on the performance of requests that have a Fedora administrator role. |
Use Cases
- Researcher Researchers control the polices on their own objects
- Distributed authentication and authorization
- University of North Carolina at Chapel Hill
- Unified Authorization
- Setting Individual Permissions
- Yale University
- Fedora managing access conditions
- Programmers use API for access condition support in external systems, i.e. HydraTitle (goal)
- Applications use API for updating access conditions stored in Fedora
- University of Wisconsin - Madison
- Islandora
- Hydra
- Avalon Media System
Container Authentication
...
- fedoraAdmin - Grants superuser permissions to the the Fedora repository. Bypasses the configured policy enforcement point (PEP).
- fedoraUser - The policy enforcement point (PEP) grants permissions on the basis of this authenticated user and the credentials on the request.
- fedoraProxy - The policy enforcement point (PEP) grants permissions on the basis of end-user security credentials that are forwarded via extended request headers.
| Info | ||
|---|---|---|
| ||
Implementations may configure the servlet container to employ any user authentication mechanism that meets specifications. This is container-specific, but usually includes JAAS, LDAP, CAS, Shibboleth, etc.. |
See the overview on configuring servlet container authentication for more details.
Additional Security Principals
...
| Info | ||
|---|---|---|
| ||
In Development: Fedora ships with a principal factory for named IP ranges. The factory may be configured with a map of names to a set of IP ranges. This allows Fedora administrators to assign privileges to all users within a named IP range, such as "On Campus". |
| Info | ||
|---|---|---|
| ||
In Development: Fedora ships with this simple principal factory that creates string-based security principals from request headers. This is useful in cases, like the Apache HTTP Shibboleth module, where additional attributes are supplied as request headers. |
OAuth 2.0 User Authentication
This feature allows a user to sign-in via a third-party service, such as Google, Yahoo or Facebook. The result of the OAuth 2.0 authentication flow is a username and access to whatever user account details are within the authorized scope, such as email address. Fedora is then free to use these user details to create a local user account or assign privileges as required for Fedora authorization. (All that this work flow provides is user authentication.)
OAuth Roles
- Client Application - Fedora
- Authorization Service - Google, etc..
- Resource Server - Fedora
OAuth 2.0 Application Authorization
From the OAuth 2.0 specification:
The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf.
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 can happen within the OAuth workflow. While OAuth is supported and encouraged, applications can still use container-level authentication, obtaining a container role and matching access. Therefore OAuth support is not required of all Fedora client applications.
OAuth Roles
- Client Application - custom front end, fedora proxy, or message-driven service
- Authorization Service - Fedora
- Resource Server - Fedora
OAuth Token Scopes
...
headers |
...
* for future consideration: A user with the fedoraUser role could grant tokens within a scope that is limited by their own user id credentials. The application would be able to act on their behalf. One token per app user is the OAuth model we commonly see. Otherwise an app would have to track which token to use within some smaller context.
FAQ
...
- Then ACL restrictions on the user would need to apply equally to the token-based requests they have authorized.
...
- Yes, access tokens may be assigned roles within the repository. This is especially useful for limited application access to a subtree.
...
. |
...
Forwarding Security Credentials
...
Fedora supports both end users and application users. It is helpful to feed both local and forwarded security credentials into a same pipeline for extracting security principals that are the basis for authorization.
The ability to forward credentials in request headers must be restricted to specific users:
...
.
Access Roles API
The access roles API is a Fedora module that allows you manage the assignment of access roles throughout the repository tree. For details, please see the Access Roles Module.
...
Fedora includes an extension point that allows installers to build their own enforcement logic for all Fedora actions. A PEP enforces appropriate access for fedora users and their proxies, i.e. applications acting on their behalf. The PEP interface is simple, for details please see Policy Enforcement PointsAuthorization Delegates. Some policy enforcement points may be roles-aware, meaning that they leverage role assignments from the Access Roles API.
| Info | ||
|---|---|---|
| ||
A policy enforcement point enforces appropriate access for fedora Fedora users and their proxies, i.e. applications acting on their behalf. One policy enforcement point may be configured at a time. |
| Info | ||
|---|---|---|
| ||
The basic roles enforcement point determines access on the basis of 4 simple roles that may be assigned throughout the repository. These are reader, metadata reader, writer, and admin. For details please see the Basic Role-based PEPAuthorization Delegate. |
| Info | ||
|---|---|---|
| ||
In Development: The XACML PEP forwards authorization requests to a XACML policy decision point. It is aware of access roles and may also make determinations on the basis of a wide range of Fedora object and datastream resource properties. Policy sets may be customized for different part of the repository tree. For detail please see the XACML PEP. |
Authorization for Non-Node REST API
These endpoints in the REST API will require the fedoraAdmin container role or the fedora administrator OAuth token scope:
| path | method | authorization |
|---|---|---|
| /rest/fcr:sitemap | any request, results are filtered | |
| /rest/fcr:search | any request, results are filtered | |
| /rest/fcr:namespaces | GET | any request |
| /rest/fcr:namespaces | POST | fedoraAdmin* |
| /rest/fcr:workspaces | GET | fedoraAdmin* |
/rest/fcr:tx | POST | any authenticated request |
| /rest/{txid}/fcr:tx/ | GET | TX must in in your servlet session |
| /rest/{tx:id}/fcr:tx/* | any | TX must be in your servlet session |
* or OAuth token with equivalent scope
Code Repository
The Fedora AuthN/AuthZ modules are in development here:
...