[ogsa-authn-bof] Use Cases

[David Chadwick]

Tom Scavo wrote:
> On 2/15/07, David Chadwick <d.w.chadwick at kent.ac.uk> wrote:
>>
>> 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
> 
> In that case, there's no need to bind the ePTID to the DN or any other
> part of the certificate as others have suggested.

Correct

> 
>> and
>> instead to require the IDP to provide the user's globally unique ID as
>> part of the set of authorisation attributes.
> 
> What globally unique ID?  Are you referring to something like
> eduPersonPrincipalName?


The ID is the one that the service requires. There is no way around 
this. The service (such as the electronic patient record system) stores 
the IDs of the patients and the doctors. The IDP must return this ID if 
the user is to gain access to the database. So what the attribute is 
called has to be determined on a bi-lateral basis between the IDP and SP 
(as do all the other authorisation attributes). EduPerson schema is one 
way of trying to globally agree these attributes. It may or may not 
succeed. I think the principal and concept are established, it is the 
implementation details that are not.

> 
>> 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.
> 
> I'm not quite understanding your suggestion, David.  Are you talking
> about Attribute Pull? 

Pull or push is irrelevant, isnt it? Pull or push is just the way of 
transporting the attributes. It does not effect the content of the 
attributes, does it. The content has to contain the globally unique user 
ID regardless of how it is obtained, push or pull.


  If so, there's a catch-22, since the Grid
> Service must supply a SAML Subject in the AttributeQuery.  That's a
> problem, and it's exactly why we've chosen to concentrate on Attribute
> Push

I think the value of the SAML Subject is irrelevant, if you consider it 
is something that is set by the IDP and is to be consumed by the AA. The 
grid service that bounces the messages between the two (IDP and AA) must 
carry this value unaltered so that the AA can understand it. In which 
case the grid CA can issue a DN which contains the random ID issued by 
the IDP, and can completely disregard the DN contents. The AA is given 
this DN and should be able to understand it, since it was effectively 
set by the IDP. Alternatively, if the IDP passes the whole set of authz 
attributes along with the authentication assertion statement, again the 
grid CA does not need to bother about what the DN contains, since all 
the information that is needed by the authz service is contained in the 
set of authz attributes, and the DN will be ignored.

So I repeat, the model is either ignore the DN, since all the 
information needed by the authz service is in the authz attributes, or 
if the authz attributes do not contain the globally unique ID of the 
user, then you have to make the DN globally unique and meaningful to the 
authz service.


>> 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.
> 
> Yes of course.  The globally unique ID need only extend to the
> boundary of the Grid, however.

If by this, you mean the boundary of the application service, then I 
agree with you, since it is the service that needs it.

   I've been trying to make the case (but
> not doing a very good job, I'm afraid) that the campuses running
> Shibboleth/SAML may not be willing and/or able to supply the globally
> unique ID that you require.
> 

Well that is a showstopper isnt it? If I run a grid electronic patient 
record service, and the PEP wont provide me with the globally unique id 
(from my perspective) of the client, then I will deny service, wont I. 
Ultimately the SP must determine what information it needs in order to 
grant access to the service.


>> 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.
> 
> Well, encryption implies SAML V2.0, which is quite a ways down the
> road.  We're rolling out deployments based on SAML V1.1 *today* so
> encryption is not an option.

this is not correct. Remember that SAMLv1.1 will carry ANY attribute 
types. So you simply define a new Encrypted Attribute Type, whose 
content is encrypted to the public key of the SP. In fact I am pretty 
sure that such attribute types are already defined, e.g. S/MIME 
enveloped data. The IDP/AA then creates the attribute type, puts it in 
the SAMLv1.1 message, and the CVS decrypts it and extracts the 
attribute. You can write a couple of plug ins for the IDP and CVS that 
do the encryption and decryption for them (they pass your code the 
attribute and you return the encrypted attribute, and vice versa)



   Moreover, encryption doesn't solve the
> problem we've been discussing (i.e., a name mapping problem).

I dont see name mapping as a problem, providing you are always mapping A 
into B and you have a rule for it. Name mapping is a problem however if 
you want to map all the letters of the alphabet into B and you dont have 
a rule for it

regards

David

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

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