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