Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 5.3

...

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.

Code Block
xml
xml
borderStylesolidxml
<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:

Code Block
xml
xml
borderStylesolidxml
<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):

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

...

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

Code Block
xml
xml
borderStylesolidxml
<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.

Code Block
xml
xml
borderStylesolidxml
<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::

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

...

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

Code Block
xml
xml
borderStylesolidxml
<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:

Code Block
xml
xml
borderStylesolidxml
<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):

Code Block
xml
xml
borderStylesolidxml
<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):

Code Block
xml
xml
borderStylesolidxml
<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>

...