[OGSA-AUTHZ] Implementations

[David Chadwick]

Hi Tom

I dont fully agree with your analysis since you have missed out the 
concept of trust. If an AA trusts an entity to act as a proxy on behalf 
of another entity (and this is actually the case we have here with the 
Grid SP acting as a proxy on behalf of the user) then the AA will be 
prepared to let the trusted proxy have the attributes of the entity it 
is acting on behalf of. There are many ways for the AA to know who it 
trusts. One way is for it to configure in the names of the trusted 
proxies (this is the easiest way but is not scalable), another is for it 
to configure in the name of a trusted entity that says who are trusted 
proxies (much more scalable since the trusted entity can authorise 
hundreds or thousands of trusted proxies) and for the trusted proxy to 
present this token to the AA. Another way would be for the user to give 
a token to the proxy saying that it authorises the proxy to act on its 
behalf, and the proxy can present this to the AA. However, this later 
model will require enhancements to the communications between the user 
and the Grid SP, which is probably a route you dont want to go down.

Note that this issue is not unique to grids. Shibboleth has a similar 
problem of determine who are trusted IDPs, and it has solved it in the 
unscalable easy way by passing the complete list of trusted IDPs in the 
meta data. Not the best choice, but a quick and easy one. So the 
solution that Valerio has currently chosen is no different to the one 
that Shibboleth has chosen

regards

David


Tom Scavo wrote:
> On Fri, Mar 21, 2008 at 9:36 AM, Valerio Venturi
> <valerio.venturi at cnaf.infn.it> wrote:
>>  The authorization problem is still unsorted. Currently the prototype
>>  allows for specifying which subjects are allowed to query for other
>>  subjects.
> 
> Right, you could implement something at the attribute authority (AA)
> that suitably restricts the set of requesters, but that doesn't solve
> the problem.  Since the profile specifies that the name identifier in
> the query is a DN, there is no way to prove user presence at the Grid
> SP.  Without proof of user presence, an SP could phish for attributes
> to its heart's content.
> 
> Note there is no such problem for the self-query (of which traditional
> VOMS is an example), rather the problem involves a query where the
> requester is acting on behalf of the subject.  In that case, the
> subject must pass some piece of information to the Grid SP that the SP
> can forward to the AA.  In Shibboleth attribute query, for example,
> that piece of information is a transient and/or encrypted identifier.
> We don't have that here, and so the profile is lacking.
> 
> Consequently, I'm convinced we've specified the name identifier in the
> query (DN) incorrectly.  The requester has to prove user presence.
> More than a  DN is needed.  Since the user is authenticating to the
> Grid SP with an X.509 certificate, the obvious conclusion is that 1)
> there is some piece of info in the cert that proves user presence, and
> 2) the SP passes the complete cert (not just the DN) to the AA.
> 
>>  I have seen that an implementation for the SAML Attribute Query for
>>  X.509 Subjects has made in as a Google Summer of Code 2008 project
>>  mentored by Globus. Keep us informed about the thing and let us know if
>>  you think that VOMS or UVOS implementations can somehow participate in
>>  the demo.
> 
> Thanks, I'll do that.
> 
> Tom
> --
>   ogsa-authz-wg mailing list
>   ogsa-authz-wg at ogf.org
>   http://www.ogf.org/mailman/listinfo/ogsa-authz-wg
> 

-- 

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

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