OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [xacml] The remaining open issues in the SAML profile


I forgot to say that we already made a decision for the second issue to 
accept my proposal, with the additional wording that the PDP uses the 
same mechanism as for internal policies.

However, I was asked to clarify the issue and we did not discuss the 
possibility that the internal policies in the PDP may reference supplied 
policies.

Best regards,
Erik


Erik Rissanen wrote:
> 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
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]