The remaining open issues in the SAML profile

[Erik Rissanen <erik@axiomatics.com>]

All,

In my previous email I wrote about issues which I think needed fixing in 
the SAML profile. We made decisions on most of those issues last week, 
but a couple of them required clarification from me.

I wrote in my email:

--8<--
*** Proposal: change wording at end of section 4.11. It says now "An 
implementation MUST be prepared to handle any circular dependencies that 
may arise". This could be interpreted such that the PDP must be able to 
resolve circularly inherited attributes among the supplied attributes in 
a SAML XACML Authz request. This is not the intent. It was meant to mean 
that the PDP must not crash or otherwise behave badly if there is a 
circular dependency. I propose that we say "An implementation is not 
required to resolve any inherited dependencies between supplied 
attributes, but MUST NOT treat any circular dependencies which may arise 
as an error or otherwise fail on them."
--8<--

On the call I promised to send an example which clarifies what I meant. 
Now that I looked at the profile text again, I noticed that I had 
misread the text, but there is still an issue, but a slightly different one.

Consider the following example (note that I am skipping some XML 
attributes to keep the example brief, so this won't validate against the 
schemas):

<samlp:XACMLAuthzDecisionQuery>
  <xacml:Request>
     ...
  </xacml:Request>
  <samlp:AdditionalAttributes>
    <samlp:AssignedAttributes>
      <samlp:Holders>
        <xacml:Match>
          <xacml:AttributeValue>Alice</xacml:AttributeValue>
          <xacml:AttributeDesignator Category="urn:....:delegate" 
AttributeId="urn:....:subject-id"/>
        <xacml:Match>
      </samlp:Holders>
      <samlp:HolderAttributes>
        <xacml:Attribute AttributeId="http://example.com/role";>
          <xacml:AttributeValue>Surgeon</xacml:AttributeValue>
        </xacml:Attribute>
      </samlp:HolderAttributes>
    </samlp:AssignedAttributes>

    <samlp:AssignedAttributes>
      <samlp:Holders>
        <xacml:Match>
          <xacml:AttributeValue>Surgeon</xacml:AttributeValue>
          <xacml:AttributeDesignator Category="urn:....:delegate" 
AttributeId="http://example.com/role"/>
        <xacml:Match>
      </samlp:Holders>
      <samlp:HolderAttributes>
        <xacml:Attribute AttributeId="http://example.com/role";>
          <xacml:AttributeValue>MedicalStaff</xacml:AttributeValue>
        </xacml:Attribute>
      </samlp:HolderAttributes>
    </samlp:AssignedAttributes>
  </samlp:AdditionalAttributes>
</samlp:XACMLAuthzDecisionQuery>

In this example the SAML profile authorization query contains extra 
attributes which apply to delegates. Who the attributes apply to are 
determined by the <Match> elements. In this case Alice holds the role 
Surgeon.

But note that there is another assigned attribute, which says that 
anybody who is a Surgeon also has the role MedicalStaff.

The above is an example of inheritance between the supplied attributes.

An example of a circular inheritance would be if there would be one more 
attribute assignment which says that anyone who is MedicalStaff is also 
Surgeon. Granted, this is a bad example, but you get the idea that in 
principle there could be cycles among the inherited attributes.

When I posted about this earlier, I thought that the profile said that 
the PDP must be able to resolve a cycle like this. However, I now 
noticed the first paragraph in section 4.11 which states that "Any 
inheritance between <AssignedAttributes> elements is not deduced", so I 
am ok with that.

What I had reacted on was that at the end of section 4.11 it also says 
that "An implementation MUST be prepared to handle any circular 
dependencies that may arise". I first thought this referred to circular 
dependencies between the supplied attributes. However, that paragraph 
actually talks about cycles which happen with the context handler, which 
is also bad, and I would like to change it.

First, let me explain what inheritance through the context handler would 
be like. Consider this example:

<samlp:XACMLAuthzDecisionQuery>
  <xacml:Request>
     ...
  </xacml:Request>
  <samlp:AdditionalAttributes>
    <samlp:AssignedAttributes>
      <samlp:Holders>
        <xacml:Match>
          <xacml:AttributeValue>Alice</xacml:AttributeValue>
          <xacml:AttributeDesignator Category="urn:....:delegate" 
AttributeId="urn:....:subject-id"/>
        <xacml:Match>
      </samlp:Holders>
      <samlp:HolderAttributes>
        <xacml:Attribute AttributeId="http://example.com/role";>
          <xacml:AttributeValue>Surgeon</xacml:AttributeValue>
        </xacml:Attribute>
      </samlp:HolderAttributes>
    </samlp:AssignedAttributes>

    <samlp:AssignedAttributes>
      <samlp:Holders>
        <xacml:Match>
          <xacml:AttributeValue>MedicalStaff</xacml:AttributeValue>
          <xacml:AttributeDesignator Category="urn:....:delegate" 
AttributeId="http://example.com/role"/>
        <xacml:Match>
      </samlp:Holders>
      <samlp:HolderAttributes>
        <xacml:Attribute AttributeId="http://example.com/role";>
          <xacml:AttributeValue>Staff</xacml:AttributeValue>
        </xacml:Attribute>
      </samlp:HolderAttributes>
    </samlp:AssignedAttributes>
  </samlp:AdditionalAttributes>
</samlp:XACMLAuthzDecisionQuery>

In this case Alice gets the role Surgeon from the supplied attributes. 
Now that the attribute Surgeon is available to the context handler, it 
is conceivable that the context handler can find more attributes which 
apply to Alice. Let's say the context handler can find that the role 
Surgeon implies the role MedicalStaff. Now, given that alice is also 
MedicalStaff, we can find the role Staff from the supplied attributes. 
Note that there was no direct inheritance between the supplied 
attributes, rather there was an intermediate step through the context 
handler.

Currently the profile draft says:

--8<--
Note that, to implement this functionality, if additional XACML 
Attributes are fetched by the Context Handler during processing, the 
implementation MUST test whether those additional XACML Attributes 
provide a match for a <xacml-samlp:Holders> element. It is also 
conceivable that the XACML Attributes provided in the 
<xacml-samlp:HolderAttributes> element may trigger XACML Attributes from 
other attribute sources available to the Context Handler.  An 
implementation MUST be prepared to handle any circular dependencies that 
may arise.
--8<--

This clearly means that the PDP must have the capability to resolve 
these forms of inheritance.

I am not fond of the idea that an implementation must be able to resolve 
inherited attributes like this. If the PDP is not required to find 
inherited attributes, then it is fairly easy to implement all this. One 
simply makes a table of the supplied attributes and for each attribute 
there is a simple condition to test against the context handler's 
attributes. However, if the PDP is required to find inherited 
attributes, the simple test becomes a graph search (through the context 
handler!), which could hurt performance, even in the case there are no 
inherited attributes.

So I would propose that the PDP is required to resolve only those 
assigned attributes which directly match the attributes available to the 
context handler in the PDP. I think we should replace the above 
paragraph with this:

--8<--
The implementation MUST match the <xacml-samlp:Holders> element against 
the attributes available to the context handler, but MUST NOT use any 
matching <xacml-samlp:HolderAttributes> to find even more attributes 
through the context handler. This implies that there can be no 
inheritance between <xacml-samlp:AssignedAttributes> elements.
--8<--



The second issue which I promised to explain is the following, from my 
previous email:

--8<--
In section 5.2, page 33, it says that the <ReferencedPolicies> MUST 
contain copies of all policies referenced from the supplied policies. I 
think this is a too strict requirement and it may in many cases be 
useful to have SAML XACML policy assertions with "external" policy 
references, and it should be allowed.

*** Proposal: Change the above mentioned MUST to a MAY in the section 5.2.
--8<--

First, there was some discussion about policies and the PDP in general. 
I said (and I still have this standpoint) that not every policy 
available to a PDP is necessarily reachable by a request at the top 
level. For instance, consider the RBAC profile, which contains several 
types of policies which have open targets and are intended to be 
reachable only through references. Let's call these kind of policies "in 
PDP reference only policies". So, if we can agree on this, there are 
(possibly) policies in the PDP which are referencable, but not directly 
reachable at the top level.

Now consider a SAML profile authz request with supplied policies:

<samlp:XACMLAuthzDecisionQuery>
  <xacml:Request>
     ...
  </xacml:Request>
  <xacml:Policy PolicyId="http://example.com/policy1";>
    ...
    <PolicyIdReference PolicyId="http://example.com/policy2"/>
    ...
    <PolicyIdReference PolicyId="http://example.com/policy3"/>
    ...
  </xacml:Policy>
  <samlp:ReferencedPolicies>
    <xacml:Policy PolicyId="http://example.com/policy2";>...</xacml:Policy>
  </samlp:ReferencedPolicies>
</samlp:XACMLAuthzDecisionQuery>

In the above, policy 1 is supplied with the request and will be combined 
with the top level policies in the PDP. Policy 1 contains two policy 
references: to policies 2 and 3.

The authz query also contains a special section of supplied policies, 
which are not combined with the top level policies in the PDP. These are 
only available through policy references.

The above mentioned text in section 5.2, page 33, in the SAML profile 
specifies that all policies referenced by the supplied policies must be 
also supplied in the <ReferencedPolicies> element. In other words, in 
the example the reference to policy 2 is ok, since it is supplied, but 
the reference to Policy 3 is not allowed since it is not supplied in the 
<ReferencedPolicies> element.

I think this is too strict. I think it would be useful to allow the 
supplied policies to refer to the in PDP reference only policies. In 
particular, and organization may have some standard policies available, 
whose Ids are known by requesters.

I also think the reverse functionality could be useful, that is, the 
policies in the PDP could contain references to policies which are 
expected to be supplied by requestors. In this case the policies in the 
PDP form a framework or template, which is augmented by supplied policies.

The sections which need to be changed are:

*** Section 4.4, change the MUST into a MAY at the end in the 
description of the <ReferencedPolicies>. Also (if we choose so) say that 
the PDP MUST use the supplied <ReferencedPolicies> for resolving any 
policy reference, even in policies already contained in the PDP. If the 
same policy id appears both in the supplied policies and the already 
contained policies in the PDP, and the conflict is not resolved by 
version constraints, then the supplied policy takes precedence.

*** Section 4.9, change the MUST into a MAY. Also (if choose so) remove 
the requirement that the supplied <ReferencedPolicies> must be referred 
from the authz query (or policy statement in case of a policy assertion).

*** Section 5.1 change the MUST into a MAY at the end in the description 
of the <ReferencedPolicies>.

*** Section 5.2, change the MUST into a MAY.

(I haven't written detailed text yet, so I think I will need to tweak 
the text a bit more to make it good and easy to understand.)

Best regards,
Erik