...
- In servlet container authentication, forwarding with require the container role of fedoraProxy.
- In OAuth token authentication, the token must include the scope forward credentials.
XACML Authorization Extension: Content Roles and Policies
Assigning 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 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)
- We can do both. I think "everyone that we know" is a subset of "everyone". How does "authenticated users" sound?
- A query can retrieve all content roles assigned to an object or a principal.
Role-Based Policy Set
Fedora provides a reference set of XACML policies formulated around each content role. These policies are written per role, so you can add whichever role/policy combinations you need to your repository. These example policies can be modified to support authorization specific to a repository.
...
- Is this something that XACML can do for us, or something we would have to rig up? - Greg Jansen
...
- see above
Access Roles API
The access roles API is a Fedora module that you manage the assignment of access roles throughout the repository tree. For details, please see the Access Roles Module.
Fedora Policy Enforcement Point (PEP)
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 Points. 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 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 PEP. |
| Info | ||
|---|---|---|
| ||
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 properties. Policy sets may be customized for different part of the repository tree. For detail please see the XACML PEP. |
...
Authorization for Other REST API Endpoints
...