Hi Tom comments below. One overall comment is this. If the PIP is receiving signed SAML assertions to validate, then it should be able to work in either push or pull mode without it making any difference. The PIP should either be given the assertion or pull it itself. Either way the validation process should be the same. So if your model does not cater for this, then I would say that the model needs updating. (Note that that OGSA Authz model does cater for this) If your model does cater for this, but the SAML assertions do not (because they are different in the push and pull cases) then I would say the assertions need changing to be the same in both cases. The other point is that the validation process should work regardless of whether the user pulled the assertion himself, or whether a grid container pulled it for him. The assertion should be the same, in both cases assigning particular attributes to a particular user. Who did the pulling is another issue and should not be of concern to the validation process, but only to the AA that is issuing the assertion. Tom Scavo wrote:
Hi Weizhong,
On Fri, May 9, 2008 at 9:31 AM, wz qiang <weizhongqiang@gmail.com> wrote:
On 5/8/08, Tom Scavo <trscavo@gmail.com> wrote:
There's a problem with the Attribute Exchange Profile it seems. If you bind a VOMS-SAML token to a SOAP message and authenticate via WS-Security SAML Token Profile, everything is fine because the key bound to the SAML token is the same key presented to the RP. "the key bound to the SAML token is the same key presented to the RP", here you meant the the key bound to SAML Token is the same key which signs the VOMS-SAML token?
No. The use case involves a user who presents an end-entity certificate to the VOMS-SAML server, and then later presents that same certificate to the RP.
It would not be the same key/certificate would it, if a proxy cert was used to the RP and not a proxy to the SAML server. The VOMS-SAML server binds the user's key (or
the entire certificate, it doesn't matter) to the SAML token. This is called holder-of-key subject confirmation.
I would say dont do that. Simply put the DN in the SAML assertion. You dont need the key if you have a proper trust infrastructure.
If so, I can not see any real scenario for this. The VOMS-SAML token (or any other attribute token) should be signed by some AA, but the "hold-of key" situation in SAML Token (WS-Security) should present the principle of the identity (which means should be the identity certificate which signed by some CA).
The SAML token is signed by the VOMS-SAML server, yes, but that's not relevant to the point I'm trying to make. In this use case, the user authenticates to the RP using the same credential used to obtain the SAML token. By proving possession of the private key associated with the certificate, the user also satisfies the holder-of-key subject confirmation in the SAML token since the key in the token is the same as the key in the certificate.
Understood, but I dont see why it will always be the same key, esp. when proxy certs are used in multiple delegations in a chain.
However, if you bind a VOMS-SAML token to a proxy certificate, there are problems since the key presented to the RP is different than the key bound to the SAML token, and so the holder-of-key subject confirmation on the assertion is not satisfied.
and this will also be the case in a long delegation proxy chain, wont it?
Why is it a problem here? Why can't we just put VOMS-SAML token into proxy certificate, and look it the same way as traditional VOMS AC (attribute certificate)?
The VOMS-SAML token as profiled is a holder-of-key token whereas the VOMS is a sender-vouches token. The SAML token is stronger than the AC.
Its not cryptographically stronger if the same crypto algs are used in both cases. You might argue that it is stronger from a trust perspective since the RP knows that the user holds the same key now as he held when he contacted the AA for the SAML assertion. But I think it is a spurious argument. If the AA is trusted (but acts fraudulently) then it could put the wrong attributes in the assertion. So then how "strong" does that make the SAML assertion with the holder of key token? Its worthless, since the attributes are wrong. So dont worry about the strength of trust in the subject field. Everything depends upon the trustworthiness of the AA to put the correct info into the SAML assertion.
In this case, the user proves possession of the private key associated with the proxy certificate, but that leaves the key in the SAML token unconfirmed.
So what? You are trusting the AA to put correct info in there. So it can just as well put the user DN in there instead of or as well as the key. 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?
Alternatively, the proxy certificate could be constructed such that its key is the same key bound to the EEC. The same as above, the AA and CA should not be mixed, I guess.
See my comments above. The issue I'm raising here has nothing to do with the signature on the token. The issue is what confirmation method to use on the SAML token? In particular, what are the consequences of downgrading the confirmation method from holder-of-key to sender-vouches?
Probably nothing in my opinion. You first need to describe your entire trust model, and who you trust for what. And then it will become apparent if there is a difference in putting a key or a DN or a cert in a SAML assertion. It is the lack of a fully worked out trust model that caused some folk to require secure time stamps from third parties to accompany attribute assertions, when they were trusting the sender with the attributes but not with the time that accompanied them! This is twisted thinking. regards David
Tom -- ogsa-authz-wg mailing list ogsa-authz-wg@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@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 *****************************************************************