...
Extension Point: Container Authentication Implementations may configure application containers to employ any user authentication mechanism the 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 a SAML payloads, etc.. Fedora provides a configurable HeaderPrincipalFactory that extracts principals from headers.
Extension Point: PrincipalFactory 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. |
|---|
Reference Implementation: IpRangePrincipalFactory 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". |
|---|
Reference Implementation: HeaderPrincipalFactory Fedora ships with this simply 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. |
|---|
Authentication of Third-Party Applications (OAuth)
...