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.
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.
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.
There is no contradiction here and there is no proxying. Instead, this simply states that if an attribute authority provides attributes that party can't then pass them around to others. I know you're in favor of this model, I am not. For those that aren't subscribed to one of the many lists on which this issue has been brought up, let me outline the basics. These assertions carry potentially sensitive information about a user. Most attribute authorities contain the ability to control the release of this information on a per-party basis (i.e. A can see/request the sensitive information but B may not). A service which passed the information it received onto another service circumvents the attribute authority and its policies. It's interesting that Tom brings up proxying. I heard many a discussion about this exact same problem, in regards to proxy credentials, at the last two middleware design meetings I attended. There are ways to securely allow one service to impersonate a user to another service, but it requires the active participation of the entity(ies) responsible for the user. Circumventing these entities may be much easier but it isn't secure. -- 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