Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Table of Contents

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.

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.

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:

  • Authentication answers the question "who is the person, and how do I verify that they are who they say they are?"  Fedora relies on the web servlet container to answer this question.
  • Authorization answers the question, "does this person have permission to do what they want to do?".  Fedora provides two different ways to answer this question:
    • Bypass authorization: Anyone who has authenticated through the web application container (Tomcat, Jetty, WebSphere, etc.) has permission to do everything – in effect all, authenticated users are superusers.
    • WebAC authorization: Authenticated users' access to resources is mediated by WebAC Access Control Lists stored in the repository.

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.

...