trscavo at gmail.com
Sat Apr 5 14:06:09 CDT 2008
Okay, if the WG deems this issue to be out of scope, I'm okay with
that. In that case, I won't touch the OASIS profile as it stands
right now. If I do decide to address this issue at some point, it
will be in a separate document.
On Sat, Apr 5, 2008 at 1:24 PM, David Chadwick <d.w.chadwick at kent.ac.uk> wrote:
> Hi Tom
> my feeling is that constructing a protocol from the end user via the GridSP
> to the IDP to prove user presence when the GridSP asks the IDP for user
> attributes, is a long term project and will require a new work item for it.
> I dont see any simple protocol solutions at the moment.
> However, there is a simple solution available now by requiring the IDP and
> GridSP to have a trust relationship which requires the GridSP to only issues
> queries when a user is present. This trust relationship can be cemented by
> the IDP configuring the names of the trusted GridSPs into its SAML service.
> This is the approach that Valerio has adopted today.
> This approach can also be scaled up to federation level by requiring
> federation members to honour this requirement, and then the IDP only needs
> to configure in the root of trust of the federation, and any federation
> member issued with a credential by the federation root becomes trusted to
> make queries from the federation IDPs.
> However, when you want to replace out of band trust with in band protocol
> to prove user presence, this becomes much more complex and I think we simply
> have to punt this for now
> Tom Scavo wrote:
> > 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.
> > > > > inclusion for example of a user's public key certificate proves
> > > > > 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
> > > > > 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
> > > > > 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
> > > > 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
> > > > 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
> > > 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
> > > shouldn't he? It should be safe. A SP can get it and go to the IdP.
> > > 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
> > > > 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
> > > > query, which proves 1) the subject presented the SAML assertion to
> > > > grid portal, and 2) the grid portal requested the Grid SP on behalf
> > > > 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
> David W. Chadwick, BSc PhD
> Professor of Information Systems Security
> The Computing Laboratory, University of Kent, Canterbury, CT2 7NF
> Skype Name: davidwchadwick
> Tel: +44 1227 82 3221
> Fax +44 1227 762 811
> Mobile: +44 77 96 44 7184
> Email: D.W.Chadwick at kent.ac.uk
> Home Page: http://www.cs.kent.ac.uk/people/staff/dwc8/index.html
> Research Web site: http://www.cs.kent.ac.uk/research/groups/iss/index.html
> Entrust key validation string: MLJ9-DU5T-HV8J
> PGP Key ID is 0xBC238DE5
More information about the ogsa-authz-wg