...
As mentioned earlier, security in Fedora is achieved through the action of servlet filters. A single DelegatingFilterProxy filter for security is defined in web.xml. This filter is configured to delegate to a FilterChainProxy, which forms the core of spring security in Fedora. This FilterChainProxy can be configured to apply any number of servlet filters based upon certain criteria such as URL path. Configuring security in Fedora, then, is a matter of choosing which servlet filters are applied to which resource URLs. Each servlet filter is itself a bean which is instantiated through Spring, and may have its own configuration and collaborators defined through spring beans. The result is a flexible
Authentication
There is a recommended choice for authentication with Fedora: FESL. There is also an experimental facility available for "upstream authentication", which is meant to allow integration with SSO services.
...
FESL
...
Upstream Auth
...
The upstream authentication filter is available as "org.fcrepo.security.http.AuthZHttpRequestAttributesFilter". It enables the use of HTTP request headers and authentication status in the Fedora access policy machinery. It requires two pieces of configuration: a header-name that contains the trusted name of the authenticated principal, and a list of header-names that contain attributes of interest. An example configuration:
| Code Block |
|---|
<bean id="upstreamAuthFilter" class="org.fcrepo.security.http.AuthZHttpRequestAttributesFilter">
<property name="principalHeader" value="name"/> <property name="names" value="age weight height"/>
</bean>
|
Assuming incoming requests are actually populated with these headers by some upstream process, and assuming that incoming requests are actually authenticated, this configuration will provide XACML policies with a subject identified by HTTP header "name" and additional attributes drawn from headers "age", "weight", and "height". In a future release of Fedora, it is possible that more flexibility will be provided to this apparatus to cover more configurations (e.g. using environment variables or HTTP headers).