[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: The remaining open issues in the SAML profile
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]