...

• 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.

...

Forwarding Security Credentials

Since applications often act on behalf of end users with extended security attributes, such as those from Shibboleth, the ability to forward credentials to a central point of authorization is key. Regardless of the approach used for authentication of third-party applications, these applications will need to forward security attributes on behalf of end users for authorization. An example of this pattern is the X-Forwarded-For header often used in web proxies, which we can use to forward the end-user IP address.

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:

• In servlet container authentication, forwarding with require the container role of fedoraProxy.
• In OAuth token authentication, the token must include the scope forward credentials.

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.

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.

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:

* or OAuth token with equivalent scope

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.)

...

• Are OAuth negotiated operations subject to the same access restrictions imposed on the user who authorized the token? (or the on-behalf-of user)
  
  • This will vary based on your authentication system. An OAuth token with on-behalf-of scope are limited to the access granted to that user, and their associated principals as retrieved by the configured principal factories. In other words, principal factories may bring more credentials into the security context. Depending upon your environment, this may or may not be equal to the access of the actual logged in user.
• Can an OAuth tokens be used as principals and assigned access roles within the repository?
  • Yes, access tokens may be assigned roles within the repository. This is especially useful for limited application access to a subtree.
• How are scopes combined?
  • Each scope imposes additional limitations upon the access granted to the token. So "read only" and "fedora administrator" combine to make a token that can read all the data in the repository. It doesn't make much sense to combine "on-behalf-of" with "fedora administrator" or "forward credentials" since the result token would effectively only have on-behalf-of X access.

Forwarding Security Credentials

...

• • -

...

• • of

...

• • X

...

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:

• In servlet container authentication, forwarding with require the container role of fedoraProxy.
• In OAuth token authentication, the token must include the scope forward credentials.

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.

Fedora Policy Enforcement Point (PEP)

...

• • access

...

• • .

...

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:

...