[OGSA-AUTHZ] Implementations

[David Chadwick]

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

regards

David

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

-- 

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

*****************************************************************