[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]