Fedora relies on the servlet container it is running in (Tomcat, Jetty, etc.) to authenticate the user. However, authorization is handled by Fedora using access control lists (ACLs) stored in the repository and defined using the Web Access Control (WebAC) vocabulary.
Fedora uses Apache Shiro to configure its authentication and authorization processes.
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.
The following sections explain the Fedora AuthN/Z framework, and provide instructions for configuring some out-of-the-box access controls.
For clarity's sake, a distinction is made between Authentication and Authorization:
Incoming requests to Fedora first pass through a series of authentication and authorization servlet filters. These filters consult the current Shiro security manager to check whether the current user is authenticated, and then what WebAC permissions they have with regards to the requested resource. Once those permissions have been determined, the WebAC filter will either reject the request with a "403 Forbidden" response, or allow it to pass on through to be processed by Fedora.
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.
Fedora uses an instance of the DefaultWebSecurityManager as its security manager. This manager is configured with two realms: ServletContainerAuthenticatingRealm and WebACAuthorizingRealm.
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.
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.
Shiro handles customization of authentication and authorization by using servlet filters. Fedora is configured with two such filters: ServletContainerAuthFilter and WebACFilter.
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.
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.