[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Decision required: Issue#70: Must Policy[Set]Id match value used in acorresponding Policy[Set]IdReference?
PROBLEM The question is, when one policy references another, as in <PolicySet ...> <Target .../> .... <PolicyIdReference>xxxx</PolicyIdReference> .... </PolicySet> referenced policy: <Policy PolicyId="yyyy"> .... </Policy> whether "xxxx" must equal "yyyy". This question may also apply to Policy[Set]IdRef values in CombinerParamters. Please state what you want the spec to say, and why. WHAT THE SPEC SAYS NOW The XACML 2.0 Specification never flat-out states that the value used in a Policy[Set]IdReference must match the value of the Policy[Set]Id used in the referenced policy, and if so, does not state the algorithm for doing the id matching. It says "The <Policy[Set]IdReference> element SHALL be used to reference a <Policy[Set]> element by id" but does state explicitly that the "id" must match the Policy[Set]Id value in the referenced policy. The non-normative examples, in describing Policy[Set]Id, say "Policy[Set] identifier. This parameter allows the policy [set] to be referenced by a policy set" but again does not explicitly say the values must match and is also non-normative. WHAT IMPLEMENTATIONS AND DEPLOYMENTS DO NOW Seth says "There are many examples of people taking advantage of the *current* behavior, which does not require that these identifiers match up. It may have been someone's intent that identifiers match, but that has never been encoded in the specification. We should be very careful about changing the current behavior." OPTIONS This needs to be clarified in XACML 3.0 and in XACML 2.0 Errata. A. If the TC decides that the values MUST match, then we need to state that explicitly and specify the matching function (probably anyURI-equal) to use. B. If the TC decides that they do not need to match (or even MUST NOT match, as one old e-mail suggested), then we need to make some bigger changes in our specs. The places I can think of are: - XACML 2.0 Core: If a PolicySet uses references even to internal Policy[Set]s, there is no way to know which ones match the reference. We need to state that the Policy[Set]IdReference value does NOT [MUST NOT?] correspond to the Policy[Set]Id in the referenced policy, and that the PDP must know via some additional undefined mechanism which policies satisfy which references. - XACML 2.0 Core: Policy[Set]CombinerParameters include a Policy[Set]IdRef that MUST be associated with a policy in the same PolicySet. We need to state that the IdRef value does NOT [MUST NOT?] correspond to the Policy[Set]Id in the referenced policy, and that the PDP must know via some additional undefined mechanism which policies satisfy which references. - XACML 3.0 Core: We might want to add an optional "ReferenceMatchValues" element to Policy[Set] to contain the Policy[Set]IdRef and Policy[Set]IdReference values it matches. This could be a many-to-many match, so we can't just stick in an XML attribute, and maybe we need to have separate lists for Policy[Set]IdRef and for Policy[Set]IdReference. Alternatively, we could add an optional element to Policy[Set]IdRef and Policy[Set]IdReference to contain the Policy[Set]Id values that it is intended to match, for cases where the implementation does not want to provide an additional implementation-specific mechanism. - SAML Profile 2.0: If an XACMLPolicyQuery requests policies according to Policy[Set]IdReferences, currently all the referenced policies are returned directly. We need to state that the PDP must know via some additional undefined mechanism which policies satisfy which references. - SAML Profile, Version 2: I would add an encapsulating element around each returned Policy[Set] that contains the Policy[Set]IdReference value(s) it satisfies. This would go into SAML Profile V2 WD4. - SAML Profile, Version 2: If an XACMLAuthzDecisionQuery passes in a set of policies, it must also supply copies of all policies referenced, either from the first set or from other referenced policies. In WD3 these are passed with no indication of which reference each policy satisfies, so in WD4, I would add an encapsulating element around each referenced policy that contains the Policy[Set]IdReference value(s) it satisfies. This would go into SAML Profile V2 WD 4. - WS-XACML: If a Requirements element in an XACMLAssertionAbstractType instance includes a policy, then it must also supply copies of all policies referenced, either from the original Requirements policy, or from another referenced policy. The WD9 does not include this, but the TC has decided it should. For WD10, I would encapsulate each policy copy in an element that specifies the value of the reference to which the encapsulated policy corresponds. - Are there others? Regards, Anne -- Anne H. Anderson Anne.Anderson@sun.com Sun Microsystems Labs 1-781-442-0928 Burlington, MA USA
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]