[OGSA-AUTHZ] holder-of-key or sender-vouches SAML token?

[David Chadwick]

Hi Tom

the answer to your question is that the RP should authenticate the 
subject itself and check that the subject is the same as the holder 
mentioned in the attribute assertion. But how the authentication is done 
cannot be determined by the AA I am afraid. It is not within its remit, 
and has somehow mixed up the trust models. Remember that the RP is in 
charge of the trust model and deciding who he trusts. So the RP is the 
correct entity to determine how to authenticate the subject, and how to 
validate the assertions from the AAs. The AA might provide advice to the 
RP, and even policy information to (try to) control use of the 
assertion, but the RP can choose to ignore the whole lot of it and do 
what it wants with the assertion.

You have two modes of access to the AA, the user himself and a third 
party. When the user accesses the AA, the AA can put something in the 
attribute assertion to say how it authenticated the user, and advise the 
RP to do the same. When the RP accesses the AA and asks for assertions 
about the subject, the AA cannot in general provide any info about how 
the subject should be authenticated by the RP. The subject might use a 
Kerberos token, un/pw, proxy cert or anything else in general. In your 
case, if this is an X.509 profile, then you can assume that PKIs and 
proxy certs will be used, so the AA could advise the RP to check that 
the DN in the assertion matches the DN in the subject's certificate. 
this would then be identical regardless of whether it was push or pull 
or ACs or SAML assertions.

regards

David



Tom Scavo wrote:
> On Sun, May 11, 2008 at 7:45 AM, David Chadwick <d.w.chadwick at kent.ac.uk> wrote:
>>> The key in the SAML token is the same as the key in the
>>> end-entity certificate, not the proxy certificate.
>>>
>>>>> Now a VOMS AC is essentially a security token with sender-vouches
>>>>> subject confirmation, so I wonder if the VOMS-SAML assertion should
>>>>> have sender-vouches subject confirmation as well.
>>>>>
>>>> I agree.
>>> That requires a change to the Attribute Exchange Profile, I'm afraid.
>>  Why not scrap the confirmation field anyway? Just have the subject DN.
>>  It is enough isnt it?
> 
> The AA doesn't have any choice with respect to the name identifier
> since the query completely determines the name identifier that the AA
> MUST use in the assertion.  The <SubjectConfirmation> element, on the
> other hand, is up to AA's discretion.  It essentially tells the RP
> what it must do to confirm the subject (and therefore accept the
> assertion).  So the question is: What should the RP be instructed to
> do to confirm the subject?  Rephrasing the question in terms of VOMS:
> What does an RP need to do to accept a VOMS AC?  The SAML assertion
> should be profiled similarly, I suspect.
> 
> 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

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