[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] Issue 86: SAML profile: Policy issuer and id of signedpolicies
Thanks Hal, This looks good to me. Regards, Erik Hal Lockhart wrote: > I agree, but suggest changing the section 5.1 text as follows. > > --8<-- > An XACMLPolicy Statement enclosed in a signed SAML assertion MAY be used as a method of authentication of XACML policies. In this case the Policy or PolicySet MUST NOT contain an XACML <PolicyIssuer> element. Instead the PDP MAY generate a <PolicyIssuer> element from the certificate or other security token associated with the signature of the SAML assertion before using the policy for XACML request evaluation. In this case the issuer of the SAML assertion SHALL be translated into an XACML attribute with id urn:FIXME:subject-id. This does that mean that the issuer name must be taken directly from the security token, merely that the PDP perform some mapping on the claims in the token to determine the issuer. > --8<-- > > Hal > > >> -----Original Message----- >> From: Erik Rissanen [mailto:erik@axiomatics.com] >> Sent: Sunday, November 16, 2008 7:32 AM >> To: XACML TC >> Subject: [xacml] Issue 86: SAML profile: Policy issuer and id of signed >> policies >> >> All, >> >> This is the remaining open issue on the SAML profile. >> >> This issue is actually two separate issues. >> >> First, we should specify that an XACML 3.0 <PolicyIssuer> element may be >> derived from the signature of a SAML assertion containing an XACML >> policy. I propose that we add the following to the SAML profile, at the >> end of section 5.1: >> >> --8<-- >> An XACMLPolicy Statement enclosed in a signed SAML assertion MAY be used >> as a method of authentication of XACML policies. In this case the Policy >> or PolicySet MUST NOT contain an XACML <PolicyIssuer> element. Instead >> the PDP MAY generate a <PolicyIssuer> element from the signature in the >> SAML assertion before using the policy for XACML request evaluation. In >> this case the issuer of the SAML assertion SHALL be translated into an >> XACML attribute with id urn:FIXME:subject-id. >> --8<-- >> >> The second issue is that, since XACML specifies that policy identifiers >> must be unique, there is a concern in case of distributed administration >> (like in the delegation profile) that someone could intentionally >> publish a policy with a duplicate id as an attack against the PDP. >> >> I propose that we add a security consideration to the 3.0 core: >> >> --8<-- >> XACML specifies that policy identifiers qualified by the policy version >> must be unique. If a PDP is provided with policies from distinct sources >> which might not be fully trusted, as in the use of the administration >> profile [FIXME ref], there is a concern that someone intentionally >> publishes a policy with an id which collides with another policy. This >> could cause policy references to point to the wrong policy and may cause >> other issues in an implementation which relies on that policy >> identifiers are unique. >> >> If this issue is a concern it is RECOMMENDED that distinct policy >> issuers or sources are assigned distinct namespaces for policy >> identifiers. One method to do this is to make sure that the policy >> identifier begins with a string which has been assigned to the >> particular policy issuer or source. The remainder of the policy >> identifier is an issuer specific unique part. For instance, Alice from >> Example Inc. could be assigned the policy identifiers which begin with >> http://example.com/xacml/policyId/alice/. The PDP can then verify that >> the authenticated source of the policy is Alice at Example Inc, or >> otherwise reject the policy. Anyone else will unable to publish policies >> with identifiers which collide with the policies of Alice. >> --8<-- >> >> 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]