...
- fedoraAdmin - Grants blanket permissions to the the Fedora repository
- fedoraUser - Grants permissions that are specific to the user or their principals, see authorization below.
| Info | ||
|---|---|---|
|
...
Container Authentication Implementations may configure application containers to employ any user authentication mechanism that meets servlet specifications. This is container-specific, but usually includes JAAS, LDAP, CAS, Shibboleth, etc.. |
Additional Security Principals
Fedora can authorize actions on the basis of a user name. Access may also hinge on additional security principals that are specific to an organization. These principals are often based on attributes coming with the request from Shibboleth, LDAP, CAS, etc.. Additional principals can be supported in Fedora authorization by implementing the PrincipalFactory interface. A PrincipalFactory examines Servlet requests and returns a set of additional principals for authorization. Example principals might include a named IP range, an affiliation or group from a Shibboleth SP header, principals extracted from SAML payloads, etc.. Fedora provides a configurable HeaderPrincipalFactory that extracts principals from headers.
Additional Security Principals
| Info | ||
|---|---|---|
|
...
Principal Factory Implementations may enhance the security context for all authorization decisions downstream by implementing a Principal Factory, which extracts additional security principals from servlet requests. Principals are extensible to whatever credential the organization wishes to privilege. Principal names must be unique. |
| Info | ||
|---|---|---|
|
...
IP Range Principal Factory Fedora ships with a principal factory for named IP ranges. The factory may be configured with a map of names to a set of IP ranges. This allows Fedora administrators to assign privileges to all users within a named IP range, such as "On Campus". |
| Info | ||
|---|---|---|
|
...
Header Principal Factory Fedora ships with this simple principal factory that creates string-based security principals from request headers. This is useful in cases, like the Apache HTTP Shibboleth module, where additional attributes are supplied as request headers. |
OAuth 2.0 Third-Party 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.)
...
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.
| Info | ||
|---|---|---|
|
...
ModeShape Authentication Provider The AuthenticationProvider is a ModeShape interface that allows implementations to authenticate JCR sessions on the basis of custom credentials. Implementations may create a custom security context here that implements highly granular JCR authorization. |
...
This is really a ModeShape extension point used internally by Fedora. For the analogous Fedora extension point, see Policy Enforcement Point (PEP). See https://docs.jboss.org/author/display/MODE/Custom+authentication+providers |
| Info | ||
|---|---|---|
|
...
Servlet Container Authentication Provider Fedora ships with a |
...
Authentication Provider that checks for proper Fedora user roles before session creation. It creates a security context that |
...
delegates ModeShape authorization decisions to the Fedora Policy Enforcement Point (PEP). |
| Info | ||
|---|---|---|
| ||
OAuth 2.0 Authentication Provider |
...
Fedora ships with an authentication provider that verifies OAuth token credentials and creates a special OAuth security context for new sessions |
...
. This provider will first enforce OAuth token scope and then delegate further authorization decisions to the Fedora Policy Enforcement Point, as appropriate for the token. |
ModeShape-Based Authorization Modules
...