...
| 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. |
...
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 allows you manage the assignment of access roles throughout the repository tree. For details, please see the Access Roles Module.
...
| 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 Container and NonRdfSourceDescription properties. Policy sets may be customized for different part of the repository tree. For detail please see the XACML Authorization Delegate. |
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:
...
/rest/fcr:tx
...
* or OAuth token with equivalent scope
...