How to write XACML Policy using Custom Attributes

Question

I'm trying to write an XACML policy that will utilize a custom attribute. I'm thinking of something like:

<?xml version="1.0" encoding="UTF-8"?>
<Policy xmlns="urn:oasis:names:tc:xacml:1.0:policy"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" PolicyId="deny-demo100"
  RuleCombiningAlgId="urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:first-applicable">
  <Description> </Description>
  <Target>
    <Subjects>
      <AnySubject/>
    </Subjects>
    <Resources>
  <AnyResource/>
</Resources>
<Actions>
  <AnyAction/>
</Actions>
  </Target>

  <Rule Effect="Deny" RuleId="rule-deny-demo100">
    <Target>
      <Subjects>
        <AnySubject/>
      </Subjects>
      <Resources>
        <Resource>
           <AnyResource/>
        </Resource>
      </Resources>
      <Actions>
        <Action>
          <ActionMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
            <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">customAttribute</AttributeValue>
            <ActionAttributeDesignator AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-    id" MustBePresent="false" DataType="http://www.w3.org/2001/XMLSchema#string"/>
          </ActionMatch>
        </Action>
      </Actions>
    </Target>    
  </Rule>

  <Rule RuleId="deny-demo100-catch-all" Effect="Permit" />

</Policy>

(We're using Fedora's XACML implementation).

I'm sure I'm missing something really simple and fundamental here, but cannot figure out what. Could someone point me in the right direction please?

Answer 1

I am not sure what you are actually looking for, but I guess you need to do some attribute-based access control.

In XACML there is a component called PIP (Policy Information Point), where you can retrieve attributes from external sources and check authorization.

This may help you: Understanding PIP (Policy Information Point).

If you need to create XACML policies in a easier way, you can follow this: XACML Policy Editor in WSO2 Identity Server.

Answer 2

What do you mean by custom attribute? What is it you want to express in 'plain old English'?

In XACML you can use any attribute you like such as role, citizenship, clearance, resource classification, time of day... Of course the availability of the attribute depends on the type of app you are protecting. How are you using the Fedora implementation? Is it for access control within Fedora Linux OS?

If you want to compare an attribute to a value e.g. citizenship == Canadian, then use a <Target/>. If you want to compare 2 attributes together e.g. clearance > classification, then use a <Condition>.

Answer 3

I have to admit I'm kinda new to XACML and Fedora's implementation of it, but my understanding is you should be able to query any value that appears when checking the user object. The URL on a default Fedora Commons install should be "localhost:8080/fedora/user" and yields the following object on my server after logging in a previously created LDAP user called "Joe User":

<user id="Joe User">
  <attribute name="uid">
    <value>userj</value>
  </attribute>
  <attribute name="mail">
    <value>[email protected]</value>
  </attribute>
  <attribute name="sn">
    <value>User</value>
  </attribute>
  <attribute name="ou">
    <value>DPT</value>
  </attribute>
  <attribute name="cn">
    <value>Joe User</value>
  </attribute>
  <attribute name="description">
    <value>sample user</value>
  </attribute>
  <attribute name="role"/>
  <attribute name="fedoraRole"/>
  <attribute name="objectClass">
    <value>organizationalPerson</value>
    <value>person</value>
    <value>inetOrgPerson</value>
    <value>top</value>
  </attribute>
  <attribute name="displayName">
    <value>Joe User (LDAP)</value>
  </attribute>
</user>

Once a value has been injected into the user object via some JAAS authentication module (as in the above case using the LDAP module) or even an environment variable you should be able to query it. In the example policy below I've set Fedora to grant fedoraAdmin like access to API-M calls if a user has an OU set to "DPT":

<?xml version="1.0" encoding="UTF-8"?>
<Policy xmlns="urn:oasis:names:tc:xacml:1.0:policy"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        PolicyId="permit-apim-to-ldap-ou"
        RuleCombiningAlgId="urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:first-applicable"
>
  <!-- test policy to approve API-M operations if a specific LDAP OU exists -->
  <!-- make sure access to API-M in premitted from the current client IP address first (check "deny-apim-if-not-in-list.xml" or "deny-apim-if-not-localhost.xml" ) -->
  <Description>note that other policies may provide exceptions to this broad policy. This policy assumes api-m users have to be authenticated</Description>
  <Target>
    <Subjects>
      <Subject> 
        <!-- specific OU - need to get this working with a range of values -->
        <SubjectMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
          <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">DPT</AttributeValue>
          <SubjectAttributeDesignator AttributeId="ou" MustBePresent="false" DataType="http://www.w3.org/2001/XMLSchema#string"/>
        </SubjectMatch>
      </Subject>
    </Subjects>
    <Resources>
      <AnyResource/>
    </Resources>    
    <Actions>
        <AnyAction/>
    </Actions>
  </Target>
  <Rule RuleId="1" Effect="Permit"/>
</Policy>

Custom attributes can even be added the Fedora XML User file (not the Tomcat user file) rather than using LDAP. Likely there is a better way to do this, but as I stated before I'm rather new to XACML and don't fully understand it. This rule works on my localhost test server based on the other rules also in place. Your mileage may vary.

Also, as stated in the sample policy file, make sure that the client you are testing from can both be permitted and then later denied API-M access before you put a rule like this in place as debugging XACML policies in Fedora seems to be extremely difficult with little data being written to the log file even in Debug mode (you will see an operation passed or failed but never the name of the rule that caused the pass/fail result to happen).