[ogsa-authn-bof] Use Cases

[David Chadwick]

Hi Tom

the solution to the dilema you describe below, is for the authz service 
to completely ignore the user ID (ePTID) that is provided by the CA, and 
instead to require the IDP to provide the user's globally unique ID as 
part of the set of authorisation attributes. In this way the grid 
service can be sure to uniquely identify the user, regardless of the 
path taken, or gateway that was used, to access it.

Ultimately there is no way around this problem. The service must have 
access to the user's globally unique ID in order to correctly enforce 
access controls. The advantage of this approach is that the IDP can 
encrypt the user's ID attribute using the public key of the ultimate 
service provider, so that the user's privacy is still protected along 
the entire access path.

regards

David


Tom Scavo wrote:
> On 2/14/07, David Chadwick <d.w.chadwick at kent.ac.uk> wrote:
>>
>> I expect everyone will have multiple globally unique IDs.
>> Global is however essential. Otherwise someone else could access my
>> patient record as me, since their ID would be identical to mine. This is
>> unacceptable.
> 
> Agreed (of course).
> 
>> So global is essential. however, as I have said before it
>> is trivial to engineer. Every system already has locally unique IDs, so
>> you prefix this with globally unique ID of the system.
> 
> No, I'm afraid it is not trivial.  (Sorry I have to delve into the
> details again :)
> 
> Today, an IdP is mostly happy to assert eduPersonPrincipalName (e.g.,
> one of my ePPNs is "trscavo at uiuc.edu").  It turns out that ePPN meets
> your requirements (as I understand them) perfectly, but Internet2 is
> pushing us (and relying parties in general) towards
> eduPersonTargetedID.  I will show that ePTID is a very different
> animal, despite the fact that it is a "globally unique ID."
> 
> An ePTID is essentially a triple:
> 
> ePTID := (IdP entityID, SP entityID, principal nameID)
> 
> The entityIDs are URIs while the nameID is opaque.  More importantly,
> note that the ePTID is scoped to the SP.  That means that SP1
> (GridShib CA), SP2 (shib-enabled Science Gateway), and SP3 (IdP Proxy)
> all receive different nameIDs from a given IdP.  This is an important
> distinction with ePPN.  It means that the Grid Service sees three
> distinct users, not a single user as seems to be required.
> 
> There isn't much that can be done about this.  The ePTID is designed
> to prevent collusion among SPs.  Unfortunately, that is exactly what
> you want to do in the presence of intermediaries.  So ePTID does not
> meet our needs (as I understand them) unless all the GridShib CAs,
> shib-enabled Science Gateways, and IdP Proxies belong to the same
> "affiliation".  But once you do that, the use of ePTID becomes
> significantly less compelling, that is, not worth the extra work
> required to deploy it.
> 
> 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

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