[OGSA-AUTHZ] Implementations

[Tom Scavo]

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.

Thanks, David.

Tom

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