[OGSA-AUTHZ] Implementations

[Valerio Venturi]

Hi,

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.

> 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?

> 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. For what concern 2, does the IdP care?

Anyway, don't you think that this would be abusing of the Subject
element? The Subject element 'specifies the principal that is the
subject of all of the statements in the assertions'. 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 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. The
consumer may use other means of passing such information, for example
WS-Security when the services are SOAP enabled.

Valerio