On Dec 10, 2007 12:37 AM, Chad La Joie <chad.lajoie@switch.ch> wrote:
Tom Scavo wrote:
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
Yes, it's supposed to be very similar to the query/request profile.
So the obvious question is why did you change the language regarding <saml:Issuer>?
The responder needs to know who is making the request.
Well, this is straightforward query, so your profile can (and probably should) build on the Assertion Query/Request Profile (which requires <saml:Issuer>). In that case, the profile reduces to little more than section 3.
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)?
Why would you find it odd that security requests/responses require integrity and confidentiality mechanisms? They are required because not doing them makes the request/response completely untrustwothy.
In regards to authentication, this one I went back and forth on. I personally think the requester and responder should always be mutually authenticated, but I could imagine cases where deployers had a more lax view, especially on the policy request. So, I just left it as a SHOULD so that individual deployments could choose not to do it, if they wanted.
Section 6.1 of [SAMLSecure] addresses the security implications of the SAML SOAP Binding. In addition, section 3.1.2 of the SAML Bindings specification [SAMLBind] provides further security guidelines regarding SAML bindings. Taken together, these security considerations adequately address this use case, I think. Additional requirements with respect to integrity and confidentiality have not been justified. Tom