...

Fedora uses Apache Shiro to configure its authentication and authorization processes.

Overview

The Fedora Authentication (AuthN) and Authorization (AuthZ) framework is designed to be flexible and extensible, to allow any organization to configure access to suit its needs.

...

Additional principal provider filters can also be added to this filter chain to do additional authorization processing. For instance, in the case where there is an external authentication system like Shibboleth that adds the user's security principals as an HTTP header to the request, you can configure the HTTP Header Principal Provider to extract the relevant principals and add them to the current user.

Security Manager

Fedora uses an instance of the DefaultWebSecurityManager as its security manager. This manager is configured with two realms: ServletContainerAuthenticatingRealm and WebACAuthorizingRealm.

ServletContainerAuthenticatingRealm

This realm takes a ContainerAuthToken, which holds a user principal and list of role names of a user that has been authenticated by the servlet container, and adds those as principals to the current Shiro user.

Normally, a Shiro authenticating realm would consult some external data source (e.g., a database, LDAP directory, etc.) to perform the actual authentication of the user. However, the way Fedora is currently configured, those checks are all handled by the servlet container, so any authentication request to this realm will return success.

WebACAuthorizingRealm

This realm determines the permissions that the current user (who may be anonymous) has with regards to the requested resource. These permissions are represented as WebACPermission objects, which consist of a pairing of an access mode (e.g., acl:Read, acl:Write) with a resource URI.

Filters

Shiro handles customization of authentication and authorization by using servlet filters. Fedora is configured with two such filters: ServletContainerAuthFilter and WebACFilter.

ServletContainerAuthFilter

This filter checks the incoming servlet request to see if there is a user principal (indicating that there is a user that has authenticated with the servlet container). It also checks if that user has either of the roles fedoraAdmin or fedoraUser. It combines the servlet user name and the role name into a ContainerAuthToken, which it uses to "log in" to the ServletContainerAuthenticationRealm. The actual credential verification has already taken place in the servlet container; this "logging in" is just to inform Shiro that there is an authenticated user, and what their name and roles are.

WebACFilter

This filter does the main work of allowing or prohibiting requests. Based on the HTTP method (and possibly other details in the headers or body of the request) of the incoming request, and the set of WebACPermission objects that the WebACAuthorizingRealm has determined for the current user, this filter will either reject the request with a "403 Forbidden" HTTP response, or allow the request to continue on to the Fedora servlet.