Page History

...

By default, Fedora XACML-based authorization is enabled. Configuration of the Fedora XACML-based Policy Enforcement Module is done in the Fedora server configuration file (fedora.fcfg). Depicted below is the section of the configuration file for the Authorization module that controls XACML-based policy enforcement.

<module role="fedora.server.security.Authorization"
        class="fedora.server.security.DefaultAuthorization">
    <comment>Builds and manages Fedora's authorization structure.</comment>
    <param name="REPOSITORY-POLICIES-DIRECTORY"
           value="/fedora-xacml-policies/repository-policies"/>
    <param name="XACML-COMBINING-ALGORITHM"
           value="com.sun.xacml.combine.OrderedDenyOverridesPolicyAlg"/>
    <param name="ENFORCE-MODE" value="enforce-policies"/>
    <param name="POLICY-SCHEMA-PATH" value="xsd/cs-xacml-schema-policy-01.xsd"/>
    <param name="VALIDATE-REPOSITORY-POLICIES" value="true"/>
    <param name="VALIDATE-OBJECT-POLICIES-FROM-DATASTREAM" value="false"/>
    <param name="OWNER-ID-SEPARATOR" value=","/>
</module>

...

To enable/disable XACML policy enforcement in Fedora, use the Fedora configuration file (fedora.fcfg). Whether Fedora uses XACML for authorization decisions is controlled by the ENFORCE-MODE parameter in the Authorization module:

<param name="ENFORCE-MODE" value="enforce-policies"/>

...

In the Authorization module section of the Fedora server configuration file (fedora.fcfg), there are parameters to set the storage location for active repository-wide policies. The Fedora repository will only know about policies that are stored within the configured policy directory location. Policies stored in any other location will be invisible to the repository and will not be loaded into the repository upon server startup! The storage location for active repository-wide policies can be set by the repository administrator using the follow parameter in Authorization module (in fedora.fcfg):

<param name="REPOSITORY-POLICIES-DIRECTORY" value="/fedora-xacml-policies/repository-policies"/>

...

Simply add the new IP address to the policy rule as follows:

<Rule RuleId="1" Effect="Deny">
  <Condition FunctionId="urn:oasis:names:tc:xacml:1.0:function:not">
    <Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:or">
      <Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-at-least-one-member-of">
        <EnvironmentAttributeDesignator
          AttributeId="urn:fedora:names:fedora:2.1:environment:httpRequest:clientIpAddress"
          DataType="http://www.w3.org/2001/XMLSchema#string"/>
        <Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-bag">
          <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">127.0.0.1</AttributeValue>
          <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">::1</AttributeValue>
          <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">111.22.333.4</AttributeValue>
        </Apply>
      </Apply>
    </Apply>
  </Condition>
</Rule>

...

There are several parameters in the Authorization module configuration that control whether Fedora will attempt to validate policies against the XML schema for XACML.

<param name="POLICY-SCHEMA-PATH" value="xsd/cs-xacml-schema-policy-01.xsd"
<param name="VALIDATE-REPOSITORY-POLICIES" value="true"/>
<param name="VALIDATE-OBJECT-POLICIES-FROM-DATASTREAM" value="false"/>
<param name="VALIDATE-SURROGATE-POLICIES" value="false"/>

...

Policy writers must understand the interaction effect of multiple XACML policies that are in scope for any particular action. The Fedora configuration file (fedora.fcfg) sets the policy combining algorithm that will be used by the Policy Enforcement Module in evaluating sets of policies. In the the Fedora server configuration file (fedora.fcfg) note the following parameter in the section for the Authorization module::

<param name="XACML-COMBINING-ALGORITHM" value="com.sun.xacml.combine.OrderedDenyOverridesPolicyAlg"/>

...

By default, the fedora-users file contains the following users, passwords, and attributes:

<users>
  <user name="fedoraAdmin" password="fedoraAdmin">
    <attribute name="fedoraRole">
      <value>administrator</value>
    </attribute>
  </user>
  <user name="fedoraIntCallUser" password="changeme">
    <attribute name="fedoraRole">
      <value>fedoraInternalCall-1</value>
      <value>fedoraInternalCall-2</value>
    </attribute>
  </user>
</users>

Notice that each attribute has a name and can have multiple values. The cases of one or two values are shown; not shown here is that an attribute can have any number of values, including none, depending on your need. The second of these entries is for Fedora internal use, and should be left intact as installed. You will probably leave the first entry in place, also as-is. But if you change the default policies, you may require additional values of the fedoraRole attribute, or additional named attributes with their own values. Additional users (with unique names) can be added with attributes as needed. This is a convenient place to define repository managers, a small number of users, or a surrogate user. An example of an additional user follows:

<users>
  <user name="testuser1" password="testuser1">
    <attribute name="someAttribute">
      <value>xyz</value>
    </attribute>
    <attribute name="fedoraRole">
      <value>researcher</value>
    </attribute>
  </user>
</users>

The above example indicates that the user has two attributes (an attribute named* "someAttriibute"* whose value is xyz, and an attribute named* "fedoraRole"* whose value is researcher). These attribute names can be used in SubjectAttributeDesignator specifications in XACML policies and the values can be used in AttributeValue specifications in policies. Below is a snippet of an XACML policy that refers to attributes from fedora-users (refer to the Fedora XACML Policy Guide for more info on policy syntax):

<Subjects>
  <Subject>
    <SubjectMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
      <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">
        administrator
      </AttributeValue>
      <SubjectAttributeDesignator AttributeId="*fedoraRole*" MustBePresent="false"
                                  DataType="http://www.w3.org/2001/XMLSchema#string"/>
    </SubjectMatch>
  </Subject>
</Subjects>

...

In Fedora, XACML policies can refer to user attribute names and values that are registered in an LDAP that is configured with Fedora's Ldap servlet filter. Refer to the Authentication and User Attributes section of the Securing Your Repository guide for information on servlet filter configuration options. Given that an LDAP is properly configured with Fedora, the Fedora XACML-based Policy Enforcement module will be able to access LDAP user attributes, which means that you can refer to LDAP attributes in reference to a Subject in a policy, as shown in the following XACML snippet (refer to the Fedora XACML Policy Guide for more info on policy syntax):

<Rule RuleId="1" Effect="Deny">
  <Condition FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-at-least-one-member-of">
    <SubjectAttributeDesignator DataType="http://www.w3.org/2001/XMLSchema#string" AttributeId="*ou*"/>
    <Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-bag">
      <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">
        Lb-Info Technology
      </AttributeValue>
      <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">
        Lb-Univ Librarian-General
      </AttributeValue>
    </Apply>
  </Condition>
</Rule>

...

The first time the Fedora repository server is started, these policies will be automatically copied into the official repository-wide policy storage location that was specified in the Fedora configuration file (fedora.fcfg). The policies are activated once they are copied into this location.

A A review of how the policy combining algorithm works, will reveal that access to a service operation cannot occur unless access is expressly permitted. The net effect of the default access control policies is that the administrator is expressly permitted to do anything (with the restriction of having to make API-M requests from the same IP address that the server runs on), and all users are expressly permitted access to API-A and OAI service requests.

...

Generally, the default repository utility policies should not be removed. They enforce core and crucial protections of the repository. Considerate understanding of how they work should proceed any (unlikely) needed editing. For example, consider and edit to permit other IPs than localhost, as opposed simply to deleting the policy.

6 Sample Policies for Typical Fedora Use

...