[OGSA-AUTHZ] Implementations

[Tom Scavo]

Sorry for not getting back to you sooner.  I got caught up in a
software release activity here at NCSA.  See inline responses below.

On Tue, Apr 1, 2008 at 12:53 PM, Valerio Venturi
<valerio.venturi at cnaf.infn.it> wrote:
>
>  On Tue, 2008-04-01 at 11:44 -0400, Tom Scavo wrote:
>  > David described a simple use case involving a proxy certificate:
>  >
>  > On Sat, Mar 22, 2008 at 5:44 AM, David Chadwick <d.w.chadwick at kent.ac.uk> wrote:
>  > >
>  > >  Secondly the inclusion of a "certificate" needs more elaboration. The
>  > >  inclusion for example of a user's public key certificate proves nothing
>  > >  more than the presence of a DN does, since it is publicly available and
>  > >  an untrustworth grid SP could send any PKC it wished, just as it can
>  > >  send any DN it wished. Therefore one needs to specify the properties of
>  > >  the certificate that are being transferred, which is, that the user is
>  > >  delegating to the grid SP to act on its behalf. A proxy certificate
>  > >  would do this, as would an attribute certificate.
>
>  A proxy proves delegation if it's used by the SP to authenticate to the
>  IdP, not if it's passed in the the query, unless you're suggesting to
>  pass the private key.

Sorry, I've been using the word "prove" inappropriately perhaps.  The
Grid SP doesn't "prove" user presence in the same way a presenter
proves possession of a private key.  The Grid SP does provide evidence
of user presence, however, some evidence being more convincing than
others, of course.

Remember, I'm not talking about self-query here, I'm talking about
standalone attribute query (also called "cold query").  If I were
managing the IdP at the University of Illinois, I would not accept
standalone attribute queries from SPs, even if I trusted the SP in
other respects.  So it doesn't matter if the SP is in metadata or on
an ACL; as an IdP I need proof (or evidence) of user presence.

For example, the UI IdP trusts all InCommon SPs, so does that mean the
UI IdP will respond to cold queries from any InCommon SP?  Any of
those SPs can put my DN into a query (at any time) and submit it to
the UI IdP, so how does the IdP know that I (the user) am actually
involved in the transaction?  Something has to be done to limit the
SP's ability to query for my attributes.

>  > Here's another possible use case involving an end entity certificate
>  > (EEC).  Suppose a user requests a short-lived EEC from a shib-enabled
>  > online CA (such as the GridShib CA).  The user first obtains a SAML
>  > assertion from the IdP and then presents this SAML assertion to the
>  > shib-enabled CA.  The CA binds the SAML assertion (or portions of it)
>  > to the issued EEC.
>  >
>  > Now the user authenticates to a Grid SP using this EEC and thereafter
>  > the SP includes the EEC in its query to the IdP.  The IdP recovers the
>  > SAML assertion in the EEC and verifies that it did in fact issue the
>  > assertion to the shib-enabled CA through the browser.  This proves (to
>  > the satisfaction of the IdP) that the user is present at the Grid SP.
>
>  I don't get what assures that the step 'the user authenticates to a Grid
>  SP using this EEC' has been going through. The EEC is public stuff, and
>  the SP could well have get it by another mean. The user, after having
>  had the EEC by the shib-enabled CA, may make it available on the web.Why
>  shouldn't he? It should be safe. A SP can get it and go to the IdP. What
>  would be different than if the user had authenticated?

Well, the first thing to note is that the EEC is short-lived (like a
typical proxy), so it's not going to be around long enough to be
abused.  Second thing to note is that a SAML assertion is
cryptographically bound to the EEC by the CA, and likewise there is a
token bound to the SAML assertion.  The IdP bound that token when I
authenticated, and only the IdP can unravel that token.  An example of
such a token is the well-known CryptoShibHandle.

>  > Another use case involves a shib-enabled grid portal (such as a
>  > TeraGrid Science Gateway) that makes a request to a Grid SP on the
>  > user's behalf.  In that case, the portal issues a proxy certificate
>  > containing the SAML assertion from the IdP, which it presents to the
>  > Grid SP.  The Grid SP recovers the SAML assertion from the proxy and
>  > uses the SAML Subject therein to issue a query to the IdP.  So neither
>  > a DN nor a certificate is required in this case.
>
>  > In the previous use case, if the IdP does not know the portal and the
>  > Grid SP are affiliated, it may reject the Grid SP's use of the SAML
>  > Subject.  Thus the Grid SP might include the entire certificate in its
>  > query, which proves 1) the subject presented the SAML assertion to the
>  > grid portal, and 2) the grid portal requested the Grid SP on behalf of
>  > the user.  The IdP may allow such a request, subject to policy.
>
>  See remark above, I don't think the certificate being in the query
>  proves 1.

Why not?  The SAML assertion has a 10-minute lifetime.  If the grid
portal does as I suggest above, in the time allotted, has the portal
not provided sufficient evidence that I (the user) very recently
visited the portal?

>  For what concern 2, does the IdP care?

As I said above, in the case of standalone attribute query (cold
query), in general the IdP very much cares that the user and the
portal are legitimately involved in the transaction.  This effectively
limits the Grid SP's ability to query for my attributes.

>  Anyway, don't you think that this would be abusing of the Subject
>  element?

Not at all.

> The Subject element 'specifies the principal that is the
>  subject of all of the statements in the assertions'.

The SP is the producer of the Subject element, not the IdP.  In a
query, it is the SP that produces the SAML Subject element.  The IdP
just follows suit (see the notion of "strongly matches" in
[SAMLCore]).

>  It's not supposed
>  to carry EEC or SAML assertions or proxy, as in the first use case.
>  Unless that is for the purpose of identifying the subject. And for
>  identifying the subject, the DN is well enough.

If the IdP trusts the Grid SP to request attributes only when there's
a legitimate user request in progress in the background, then yes, a
DN will suffice.  In general, that trust may not exist, so we need a
mechanism that an SP can use to "prove" (maybe that's too strong of a
word) user presence.

>  If a IdP requires by authz policy that the EEC of the subject is
>  passed, I don't think we should force the query to allow that.

No, I never said the SP MUST use a certificate, but I don't think the
SP MUST use a DN either.  (I've just outlined a use case where neither
is required in fact.)  In the case of query (not self-query), here's
the suggested normative language:

- An SP MAY use an X509SubjectName name identifier or an identifier of
type KeyIdentifierType.  [The latter was defined previously, as a
suitably constrained <ds:KeyInfo> element.]

- An IdP MUST support X509SubjectName.  Other NameID formats,
including KeyIdentifierType, MAY be supported by the IdP.

>  The
>  consumer may use other means of passing such information, for example
>  WS-Security when the services are SOAP enabled.

I know of no WSS profile that covers this use case where the requester
is acting on behalf of the subject.  That said, that's an interesting
idea, putting an X.509 token in the SOAP header, and a SAML request in
the SOAP body.  That requires quite a bit more than an ordinary SAML
SOAP responder, however.  It would be much harder to implement.

Tom