...
| 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.. |
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.databases and other sources. Additional principals can be supported included in Fedora authorization by implementing the a PrincipalFactory interface. A PrincipalFactory examines Servlet requests and returns a set of additional principals for authorization. Example principals might Examples 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 | ||
|---|---|---|
| ||
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 | ||
|---|---|---|
| ||
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 | ||
|---|---|---|
| ||
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.)
...