...
| 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 the servlet container or OAuth tokens, 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 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
...
| 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
...
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 | ||
|---|---|---|
| ||
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 properties. Policy sets may be customized for different part of the repository tree. For detail please see the XACML PEPAuthorization Delegate. |
Authorization for Non-Node REST API
...