Date: Tue, 19 Mar 2024 01:04:18 -0400 (EDT) Message-ID: <2124505762.8631.1710824658730@lyrasis1-roc-mp1> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_8630_1847887957.1710824658730" ------=_Part_8630_1847887957.1710824658730 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
User authentication is generally handled by the Servlet container, i.e. = Tomcat, JBoss AS, Jetty, etc. Authenticated requests will arrive at Fedora = servlets with a non-null values for getRemoteUser() and getUserPrincipal().=
Fedora users may have the following servlet container roles.
Extension Point: Container Authenticat= ion
Implementations may configure the servlet container to employ any user a= uthentication mechanism that meets specifications. This is container-specif= ic, but usually includes JAAS, LDAP, CAS, Shibboleth, etc..
See the overview on How to Configure Servlet Container Authenticat= ion for more details.
Access may hinge on additional security principals that are specific to = an organization. These principals are often based on Shibboleth, LDAP, CAS,= databases and other sources. Additional principals can be included in auth= orization by implementing a PrincipalFactory. A PrincipalFactory examines S= ervlet requests and returns a set of additional principals. Examples includ= e a named IP range, an affiliation or group from a Shibboleth header, princ= ipals extracted from SAML payloads, etc.. Fedora provides a configurable He= aderPrincipalFactory that extracts principals from headers.
Extension Point: Principal Factory
=Implementations may enhance the security context for all authorization d= ecisions downstream by implementing a Principal Factory, which extracts add= itional security principals from servlet requests. Principals are extensibl= e to whatever credential the organization wishes to privilege. Principal na= mes must be unique.
Reference Implementation: IP Range Pri= ncipal Factory
In Development: Fedora ships with a principal factory f= or 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: Header Princ= ipal Factory
In Development: 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 ad= ditional attributes are supplied as request headers.
Since applications often act on behalf of end users with extended securi= ty attributes, such as those from Shibboleth, the ability to forward creden= tials to a central point of authorization is key. Regardless of the ap= proach used for authentication of third-party applications, these = applications will need to forward security attributes on behalf of end user= s for authorization. An example of this pattern is the X-Forwarded-For header often used in web proxies, wh= ich we can use to forward the end-user IP address.
Fedora supports both end users and application users. It is helpful to f= eed both local and forwarded security credentials into a same pip= eline for extracting security principals that are the basis for author= ization.
The access roles API allows you manage the assignment of access roles th= roughout the repository tree. For details, please see the Access Roles Module.
Fedora includes an extension point that allows installers to build their= own enforcement logic for all Fedora actions. A PEP enforces appropriate a= ccess for fedora users and their proxies, i.e. applications acting on their= behalf. The PEP interface is simple, for details please see Authorization Delegates= . Some policy enforcement points may be roles-aware, meaning that they leve= rage role assignments from the Access Roles API.
Extension Point: Policy Enforcement Po= int (PEP)
A policy enforcement point enforces appropriate access for Fedora users = and their proxies, i.e. applications acting on their behalf. One policy enf= orcement point may be configured at a time.
Reference Implementation: Basic Roles = PEP
The basic roles enforcement point determines access on the basis of 4 si= mple roles that may be assigned throughout the repository. These are reader= , metadata reader, writer, and admin. For details please see the Basic Role-bas= ed Authorization Delegate.
Reference Implementation: XACML PEP
In Development: The XACML PEP forwards authorizat= ion requests to a XACML policy decision point. It is aware of access roles = and may also make determinations on the basis of a wide range of Fedora res= ource properties. Policy sets may be customized for different part of the r= epository tree. For detail please see the XACML Authorization Delegate.