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