[OGSA-AUTHZ] Implementations

Tue Apr 1 10:44:09 CDT 2008

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.

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.

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.

Tom

On Tue, Apr 1, 2008 at 9:41 AM, Valerio Venturi
<valerio.venturi at cnaf.infn.it> wrote:
> Hi,
>  I'm sorry to jump into the exchange so late, but I wasn't able to do it
>  before.
>  I was reading the thread, and everything is pretty smooth until
>  David's March 22th 10:44 mail. At that point, to my understanding, it's
>  not cleat whether there's really a problem with the OASIS profile.
>  What Tom has brought to our attention is that profile would lack the
>  possibility for the IdP that receives a query to determine whether the
>  requester is authorized to get the subjet's attributes. Intially, the
>  problem was stated as proving user presence at the SP, but I think it's
>  more generally an authz problem. User presence it's only a possible
>  policy the IdP may have for authorizing requests. The IdP has to decide
>  whether to allow the request, and each service will have policies for
>  that. I wouldn't suggest doing as I did in the prototype, allowing after
>  the SP's DN, but it's a way. Or, the IdP may issue an authorization
>  decision query to a PDP.
>  I don't see this as a protocol problem. It can become a protocol problem
>  if the protocol doesn't allow to pass all the info needed to the IdP to
>  drive his authorization decision. But I haven't understood why the cert
>  would say much more than the dn for that.
>  Before discussing how to handle a problem with the spec, can you help me
>  understand that?
>
>  Valerio
>
>
>
>
>
>  On Sat, 2008-03-22 at 10:31 -0400, Tom Scavo wrote:
>  > On Sat, Mar 22, 2008 at 5:44 AM, David Chadwick <d.w.chadwick at kent.ac.uk> wrote:
>  > >
>  > >  ...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.
>  >
>  > I totally agree.  Of course this requires a new attribute request
>  > handler at the Shib AA but then a new handler is required for a bare
>  > DN as well, so there's no additional penalty.  I don't know that much
>  > about the VOMS AA, but I'd be surprised if handling a full certificate
>  > turned out to be much of a problem for VOMS.
>  >
>  > We have a dilemma, however.  A formal ballot is currently underway to
>  > promote the OASIS SAML V2.0 Deployment Profiles for X.509 Subjects to
>  > Committee Specification status.  I fully expect this ballot to
>  > succeed.  The next step after Committee Specification is OASIS
>  > Standard (but this last step requires three attestations, which is
>  > unlikely).
>  >
>  > If we introduce a normative change to the profile such as we've been
>  > discussing, we essentially start over.  Presumably the profile could
>  > travel faster through committee this time around since the bulk of it
>  > has already been vetted, but a significant delay is inevitable.
>  >
>  > The other alternative is to specify this new extension of
>  > saml2:BaseIDAbstractType in our Attribute Exchange profile and leave
>  > the OASIS profile alone, flawed as it is.  A third alternative is to
>  > do nothing.
>  >
>  > I'm not sure what to recommend.  I'll let others comment on the
>  > appropriate course of action.
>  >
>  > Tom
>  >
>  > >  Tom Scavo wrote:
>  > >  >
>  > >  > Instead of *requiring* a DN, the name identifier in the query should
>  > >  > be generalized to accommodate the entire certificate (without
>  > >  > excluding the possibility of a naked DN in those situations where it
>  > >  > is warranted).  This can be done using <ds:KeyInfo>, something like
>  > >  > this:
>  > >  >
>  > >  > <saml:Subject>
>  > >  >  <saml:BaseID xsi:type="KeyIdentifierType">
>  > >  >    <ds:KeyInfo>...</ds:KeyInfo>
>  > >  >  </saml:BaseID>
>  > >  > </saml:Subject>
>  > >  >
>  > >  > where KeyIdentifierType is defined as follows:
>  > >  >
>  > >  > <complexType name="KeyIdentifierType">
>  > >  >  <complexContent>
>  > >  >   <extension base="saml:BaseIDAbstractType">
>  > >  >     <sequence>
>  > >  >       <element ref="ds:KeyInfo"/>
>  > >  >     </sequence>
>  > >  >   </extension>
>  > >  >  </complexContent>
>  > >  > </complexType>
>
>