Overview
The Fedora 4 Authentication and Authorization 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 4 AuthNZ 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 4 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 4 provides three different ways to answer this question:
- Simple servlet container authentication. 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.
- Basic Access Roles authorizations. Authenticated users are mapped onto one or more preconfigured roles; a user's role determines what they have permission to do.
- XACML authorizations. Policies created using the XACML framework are used to determine what operations are permissible to whom, using user and object properties exposed to the XACML engine.
Servlet Container Configuration
The superuser role is fedoraAdmin. This is comparable to the fedoraAdmin superuser role in Fedora 3, used for Fedora 3 API-M operations.
If you are starting from the pre-packaged authorization war file (fcrepo-webapp-<version>-auth.war), you should skip to step #4 below.
Configure your repo.xml file
Add the beans authenticationProvider and fad to your repo.xml file, and make the modeshapeRepofactory bean dependent on authenticationProvider. Use the class org.fcrepo.auth.ServletContainerAuthenticationProvider as your authentication provider. Here is an example repo.xml that configures authentication and authorization using the Basic Roles authorization delegate:
repo.xml with authentication configured<?xml version="1.0" encoding="UTF-8"?> <beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:context="http://www.springframework.org/schema/context" xmlns:p="http://www.springframework.org/schema/p" xmlns:util="http://www.springframework.org/schema/util" xsi:schemaLocation=" http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.0.xsd http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-3.0.xsd http://www.springframework.org/schema/util http://www.springframework.org/schema/util/spring-util.xsd"> <!-- Context that supports the actual ModeShape JCR itself --> <context:annotation-config/> <bean name="modeshapeRepofactory" class="org.fcrepo.kernel.impl.spring.ModeShapeRepositoryFactoryBean" p:repositoryConfiguration="${fcrepo.modeshape.configuration:classpath:/config/servlet-auth/repository.json}" depends-on="authenticationProvider"/> <bean class="org.modeshape.jcr.JcrRepositoryFactory"/> <!-- Optional PrincipalProvider that will inspect the request header, "some-header", for user role values --> <bean name="headerProvider" class="org.fcrepo.auth.common.HttpHeaderPrincipalProvider"> <property name="headerName" value="some-header"/> <property name="separator" value=","/> </bean> <util:set id="principalProviderSet"> <ref bean="headerProvider"/> </util:set> <bean name="fad" class="org.fcrepo.auth.roles.basic.BasicRolesAuthorizationDelegate"/> <bean name="authenticationProvider" class="org.fcrepo.auth.common.ServletContainerAuthenticationProvider"> <property name="fad" ref="fad"/> <property name="principalProviders" ref="principalProviderSet"/> </bean> <!-- For the time being, load annotation config here too --> <bean class="org.fcrepo.metrics.MetricsConfig"/> </beans>
Configure your repository.json file
Modify the security section to enable both authenticated (via authentication provider) and internal sessions between Fedora and ModeShape. It should match this block:
repository.json security"security" : { "anonymous" : { "roles" : ["readonly","readwrite","admin"], "useOnFailedLogin" : false }, "providers" : [ { "classname" : "org.fcrepo.auth.common.ServletContainerAuthenticationProvider" } ] },
Configure your web.xml
Configure your web.xml.Modify fcrepo-webapp/src/main/webapp/WEB-INF/web.xml by uncommenting the security configuration
<!--Uncomment section below to enable Basic-Authentication--> <security-constraint> <web-resource-collection> <web-resource-name>Fedora4</web-resource-name> <url-pattern>/*</url-pattern> <http-method>DELETE</http-method> <http-method>PUT</http-method> <http-method>HEAD</http-method> <http-method>OPTIONS</http-method> <http-method>PATCH</http-method> <http-method>GET</http-method> <http-method>POST</http-method> </web-resource-collection> <auth-constraint> <role-name>fedoraUser</role-name> <role-name>fedoraAdmin</role-name> </auth-constraint> <user-data-constraint> <transport-guarantee>NONE</transport-guarantee> </user-data-constraint> </security-constraint> <login-config> <auth-method>BASIC</auth-method> <realm-name>fcrepo</realm-name> </login-config>
The "auth-constraint" element must contain the roles defined as your users (see below for jetty and tomcat).Configure your web application container
Jetty
Create your jetty-users.properties file. This file contains entries in the format username: password [, role, ...], where
- username is the user's login id (the principal)
- password is the user's password
- role is the servlet role they are assigned upon login; jetty allows you to specify any number of roles (or no role at all). Fedora currently supports two roles: fedoraAdmin, which is the superuser role, and has rights to do everything; and fedoraUser, which is a user role, and must be granted permissions by the Policy Enforcement Point to perform actions.
Sample jetty-users.properties file that contains three users, two of whom are regular users, and the third of whom (fedoraAdmin) is a Fedora superuser:
jetty-users.propertiestestuser: password1,fedoraUser adminuser: password2,fedoraUser fedoraAdmin: secret3,fedoraAdmin
- Configure your Jetty login realm.
Standalone
Modify your jetty.xml file to configure the login realm and include the jetty-users.properties file:jetty.xml login service<Configure class="org.eclipse.jetty.webapp.WebAppContext"> <!-- Set this to the webapp root of your Fedora 4 repository --> <Set name="contextPath">/</Set> <!-- Set this to the path of of fcrepo4 WAR file --> <Set name="war"><SystemProperty name="jetty.home" default="."/>/webapps/fcrepo4</Set> <Get name="securityHandler"> <Set name="loginService"> <New class="org.eclipse.jetty.security.HashLoginService"> <Set name="name">fcrepo4</Set> <!-- Set this to the path to your jetty-users.properties file --> <Set name="config"><SystemProperty name="jetty.home" default="."/>/path/to/jetty-users.properties</Set> </New> </Set> </Get> </Configure>
Embedded in Maven
- The fcrepo-webapp Maven project includes jetty-maven-plugin. The property jetty.users.file sets the location of the jetty-users.properties file. Run the fcrepo-webapp server with the following system property:
-Djetty.users.file=/path/to/jetty-users.properties
See the Jetty Authentication documentation for more details.
Tomcat
- Create or edit your
$CATALINA_HOME/conf/tomcat-users.xml
file. It has entries of the form<user name="principal" password="password" roles="role1, role2, ..." />
where:
- name is the user's login id (the principal)
- password is the user's password
- roles are the servlet roles they are assigned upon login; tomcat allows you to specify any number of roles (or no role at all). Fedora currently supports two roles: fedoraAdmin, which is the superuser role, and has rights to do everything; and fedoraUser, which is a user role, and must be granted permissions by the Policy Enforcement Point to perform actions.
Sample tomcat-users.xml file that contains three users, two of whom are regular users, and the third of whom (fedoraAdmin) is a Fedora superuser:
tomcat-users.xml<tomcat-users> <role rolename="fedoraUser" /> <role rolename="fedoraAdmin" /> <user name="testuser" password="password1" roles="fedoraUser" /> <user name="adminuser" password="password2" roles="fedoraUser" /> <user name="fedoraAdmin" password="secret3" roles="fedoraAdmin" /> </tomcat-users>
Configure your Tomcat login realm.
Modify your file$CATALINA_HOME/conf/server.xml
file to configure the login realm with the Fedora 4 webapp context:Tomcat server.xml Realm<Context> ... <Realm className="org.apache.catalina.realm.UserDatabaseRealm" resourceName="UserDatabase" /> </Context>
See the Tomcat Realms documentation for more details.
- Create or edit your
Policy Enforcement Points
Access Roles Module
Overview
This module creates a REST API to assign new roles to identities and to query the roles already assigned on Fedora resources.
In roles-based access control, users or groups are not granted specific actions on resources; rather, users and groups have roles assigned to them on resources, and these roles are mapped onto permitted actions elsewhere. This makes it much easier to manage permissions globally: rarely will masses of resources need to be updated if their permissions change. Only the role-to-permission mapping will be updated. Role-based access control is a common pattern in security, providing extensible role-specific behavior while retaining straightforward management.
This module does not define any specific roles or enforce permissions granted to roles. For roles to be effective, this module must be configured alongside an authorization delegate that is aware of roles. One roles-aware authorization delegate is provided as a reference implementation, the Basic Roles-Based Authorization Delegate.
REST API
The module adds another REST endpoint to every Fedora resource path. The URL pattern is as follows:
<path to Container>/fcr:accessroles
REST methods:
method | description |
---|---|
GET | Retrieves the roles assigned on a resource. |
GET w/effective parameter | Retrieves the effective roles assigned on a resource, which may cascade from an ancestor role assignment. |
POST | Sets all the roles assigned on a resource. |
DELETE | Removes any roles assigned on a resource, such that effective roles are inherited again. |
The POST and GET methods currently support a JSON structure (as Content-type application/json) where principals are mapped to lists of roles:
{
"johndoe" : [ "reader" ],
"janedoe" : [ "writer" ],
"freddoe" : [ "patron", "editor" ]
}
This module assigns one or more roles to a string, which is the name of a security principal. (java.security.Principal) The principals used in your repository environment must have unique names. You may use whatever principals you wish, but we recommend applying the appropriate standard for your environment. This module does not validate principal names.
Fedora uses a principal named "EVERYONE" to represent the general public. This principal is added to every incoming web request. You may assign any role to the EVERYONE principal.
By default, role names are not validated, since the module does not define the set of role names that may be assigned in Fedora. However, you may configure a set of specific roles and then the API will validate roles.
Example Data
root/ (default content roles, i.e. no roles for anyone) ├── Container A (EVERYONE => reader; johndoe => admin) │ ├── Binary 1 (johndoe => admin) │ └── Container Q (EVERYONE => reader; johndoe => admin) │ └── Container R (janedee => admin) ├── Container B (EVERYONE => reader; johndoe => admin) │ └── Container T │ └── Container V └── Container C
Inheritance of Effective Roles
Descendant resources inherit the roles assigned on ancestor resources only if they have no roles assigned themselves. If a resource has any roles assigned, these assignments override ALL ancestor assignments.
The following cases, based on the example data above, demonstrate how inheritance plays out.
- Binary 1 of Container A only allows one principal to access the resource: johndoe. He will have admin privileges. None of the ACLs on Container A will be applied; the binary will not inherit the EVERYONE => reader ACL on Container A.
- Container R, a child of Container Q, has its own content ACL: janedee has admin privileges on Container R. No one else has any access to the resource, not even the parent resource (Container Q) principals (EVERYONE and johndoe).
- Container T, a child of Container B, has no content ACLs. So it inherits the ACLs of its most immediate ancestor with content ACLs: Container B. EVERYONE has reader privileges on Container T, and johndoe has admin privileges on the Container.
- Container V also inherits the ACLs of Container B (its most immediate ancestor with content ACLs).
- Container C has no content ACL; it inherits the ACLs of the root resource, which is to say, nothing. No one other than fedoraAdmin has any access to this Container.
Cascading Delete Permission
When deleting a resource, the user must have an effective role that will allow them to delete ALL the descendant Containers under the resource. (binaries, child Containers, etc..) If any descendant resource cannot be deleted, then the entire delete transaction will be denied.
For example, in the graph shown above, the principal johndoe cannot delete container A, although he has an admin role on it and its binary; that is because he does not have an effective role on Container R, the resource's grandchild, that will permit him to delete it. If he wants to delete Container A, he will first have to ask janedee to delete Container R.
Authorization Operations and Example
(Editor's note: this section would make more sense within the Basic Roles auth delegate documentation/page)
Order of operation:
- Container Authentication: A user comes into the system. They are assigned a user principal:
- If they authenticate through some authentication gateway, then their principal may be generated from some of the person's attributes;
- Whether they authenticate or not, the request will always acquire an "EVERYONE" principal.
- Fedora Principal Provider extensions: Principal provider extensions may bring in more principals after authentication, such as groups, from sources like LDAP.
- Fedora Roles Authorization Delegate Queries for Assigned Roles on Content: What roles have been assigned?
- The authorization layer queries the requested repository resource(s) for any content-assigned roles.
- If none are found locally, then it will query each ancestor in turn until role assignments are found.
- If no role assignments are found in the tree of resources, then a default set of role assignments is used. (see Container C above)
- Fedora Roles Authorization Delegate - Role Resolution: What roles does this request have?
- The set of principals in the request are compared to the principals in the ACLs on the resource. The roles for each matching principal in the Container ACL are the effective roles for the user.
- At this point we have the effective access roles for this operation
- Fedora Roles Authorization Delegate - Policy Enforcement: Does this role have permission to perform the requested action?
- Note: The Fedora Authorization Delegate is an extension point, so enforcement will vary by the chosen implementation. We assume that installations will combine the access roles module with a roles-based authorization delegate.
- The effective roles, assigned to the user on the content, are used to determine if the user has permission to perform the action on a given resource.
- Basic Roles authorization delegate implementation does permission checks in java code:
- Permission is determined by evaluating at a minimum the effective roles for the user on the resource in question, and the action requested.
- In other roles-based authorization delegate implementations, more factors may also enter into the equation to determine permission.
- The authorization delegate will return a response to ModeShape, which will throw an exception to Fedora if access has been denied.
- Fedora will respond with a 403 if the given REST operation is denied.
- The one exception to this process is the fedoraAdmin container role. If the request has a fedoraAdmin user role (in the container), then no resource checks are made. The authorization delegate is not consulted as admins have permission to do everything. Resources will never have the fedoraAdmin role explicitly assigned to them, since it is a container role and not a content role. (e.g. a tomcat user role)
Examples:
- Unauthenticated user requests to see Container A.
- The user is assigned the user principal "EVERYONE".
- The authorization delegate intercepts the request, gets the ACLs for Container A: "EVERYONE" => "reader" and "johndoe" => "admin".
- The authorization delegate compares the user principal "EVERYONE" to the principals in Container A's ACLs, and sees that "EVERYONE" matches. The effective role for this request is "reader", the role paired with the principal "EVERYONE" on the Container.
- The authorization delegate sees if the role "reader" can view the Container; it can.
- The authorization delegate returns "yes", and the request proceeds.
- Unauthenticated user requests to see binary 1 on Container A.
- The user is assigned the user principal "EVERYONE".
- The authorization delegate intercepts the request, gets the ACLs for binary 1: "johndoe" => "admin".
- The authorization delegate compares the user principal "EVERYONE" to the principals in binary 1's ACLs, but does not find a match.
- The authorization delegate returns "no", and the request is denied.
- Unauthenticated user requests to delete Container B.
- The user is assigned the user principal "EVERYONE".
- The authorization delegate intercepts the request, gets the ACLs for Container B: "EVERYONE" => "reader" and "johndoe" => "admin".
- The authorization delegate compares the principal "EVERYONE" to the principals in Container B's ACLs, and sees that "EVERYONE" matches. The effective role for this request is "reader", the role paired with the principal "EVERYONE" on the Container.
- The authorization delegate sees if the role "reader" can delete the Container; it cannot.
- The authorization delegate returns "no", and the request is denied.
- John Doe requests to update binary 1 on Container A.
- The user is assigned the user principals "johndoe" and "EVERYONE".
- The authorization delegate intercepts the request, gets the ACLs for binary 1: "johndoe" => "admin".
- The authorization delegate compares the user principals "johndoe" and "EVERYONE" to the principals in binary's ACLs, and sees that "johndoe" matches. The effective role for this request is "admin", the role paired with the principal "johndoe" on the Container.
- The authorization delegate sees if the role "admin" can update the Container; it can.
- The authorization delegate returns "yes", and the request proceeds.
Basic Role-based PEP
XACML PEP
OAuth
Bypassing Authorization
This configuration does not preclude the use of container authentication to secure Fedora. However, container roles are not used for any further authorization within Fedora. All requests are treated as superusers.
The security bypass for REST endpoint is accomplished by supplying an alternate ModeShape authentication provider for servlet credentials. This servlet authentication provider permits all actions at the modeshape level and does not use a PEP (Policy Enforcement Point).
Step-by-Step:
- If you previously configured a PEP, open your repo.xml file and remove any beans that are instances of "org.fcrepo.auth.common.ServletContainerAuthenticationProvider".
- Also remove the PEP bean, if one was configured.
- Remove the depends-on attribute on the modeshapeRepofactory bean, if there is one.
- Open your repository.json file
- Under security, configure the "BypassSecurityServletAuthenticationProvider", as shown in the example below.
Example repository.json (security section)
"security" : { |
---|