[OGSA-AUTHZ] Draft XACML/SAML Protocol Profile

[Chad La Joie]

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 at switch.ch, http://www.switch.ch