Hi Chad, I'm sure you know this but if you change all the normative language regarding <saml:Issuer> from SHOULD to MUST, you essentially end up with the Assertion Query/Request Profile in section 6 of the SAML V2.0 Profiles spec: http://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf So the obvious question is why did you change the language regarding <saml:Issuer>? Overall, your profile is a curious blend of more restrictive / less restrictive language with respect to the profiles it depends on. The stated requirements on <saml:Issuer> are an example of the latter. The security requirements in section 3 seem to be an example of the former. In particular, I find it odd that integrity and confidentiality are MUSTs, yet authentication is SHOULD. Can you say a few words about that (beyond what's already written in the document)? Finally, the restriction on lines 178--180 seems to contradict sections 6.1 and 7 of the SAML-XACML profile. Why restrict carte blanche the proxying of the <saml:Assertion> by the requester? Not only does that contradict the SAML-XACML profile but it's clearly out of scope for your use case. Tom On Dec 3, 2007 9:54 AM, Chad La Joie <chad.lajoie@switch.ch> wrote:
For part of some EGEE work that I'm involved in I came up with a profile, in draft form currently, for the XACML over SAML protocol defined within the OASIS XACML working group. Valerio suggested that I make it available to this working group for possible adoption in your efforts.
The draft can be found here: http://switch.ch/grid/support/documents/xacmlsaml.pdf
The basic goal of the document is to restrict possible options into a baseline subset such that discreet implementations might inter-operate. I think Valerio's summary of the document, as follows, is good: - requirement for using the SAML SOAP binding as in SAMLBind - requirement for having mutual authentication between the requester and the responder - some requirements on the elements usage - requirements on authN, integrity and confidentiality
Note this document is only about interoperability at the protocol level, it does not speak to the other necessary item here which is a profile for the information (attributes) within the XACML request/response context. I know that individuals here have already been working on such a document.
Comments are welcome to the document. We will be going forward with an immediate implementation of this draft for the EGEE work, but that should only be taken as a reflection of a constrained timeline for a short-term project, not as an indication that the profile is already as good as possible.
-- SWITCH Serving Swiss Universities -------------------------- Chad La Joie, Software Engineer, Security Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland phone +41 44 268 15 75, fax +41 44 268 15 68 chad.lajoie@switch.ch, http://www.switch.ch -- ogsa-authz-wg mailing list ogsa-authz-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-authz-wg