[OGSA-AUTHZ] Draft XACML/SAML Protocol Profile

[Tom Scavo]

On Dec 10, 2007 12:37 AM, Chad La Joie <chad.lajoie at 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