[OGSA-AUTHZ] Implementations

[Valerio Venturi]

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>