...

A user with the fedoraAdmin role may authorize application access without any limits upon scope, including access equivalent to the fedoraAdmin role. A user with the fedoraUser role can only grant tokens within a scope that is limited by their own user credentials, since the application will only be able to act on their behalf. For specifics see the OAuth section below.

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 Regardless of the approach used for authentication of third-party appsapplications, certain these applications will need to forward security attributes on behalf of end users .

Discussion: These break down into two categories, named principals and credentials. The distinction is whether Fedora or the third part application constructed the distinct security principals used for authorization. To illustrate we take the example of an IP restriction. Let's say that the authorization policy, regardless of implementation, says that users "on campus" can access a resource, but otherwise they cannot. The third party can support this authorization in two ways. It can provide the IP address of the end user request or it can provide the named security principal "on campus".

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 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. In mixed authentication environments, i.e. Fedora instances that support end-user and application requests, it is helpful to channel security credentials into a same pipeline for extracting the security principals that are the subject of 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 "forwardCredentials".
• In OAuth token authentication, the token must include the scope "forwardCredentials"
• Container User Role: forward credentials
• OAuth Token Permission: forward credentials

Establishing JCR Sessions

...

JCR authentication is based on ServletCredentials that are passed through from the REST endpoint. The place to start looking at this is the SessionFactory, which retrieves the transaction session or formulates a repository login attempt from the servlet request. Repository logins are based on an extensible credentials object. In ModeShape logins may be implemented by many implementations of an AuthenticationProvider interface. Fedora includes an ServletAuthenticationProvider that checks requests for a Fedora user role of either fedoraUser or fedoraAdmin before permitting Session creation.

...