On Fri June 26 2009 4:03:56 am Fintan Bolton wrote: > Mayank Mishra-3 wrote: > AFAIK,* In case of Public Key as Key Type,* client doesn't want to trust > STS for issuing the secret key as proof of possession. In the RST
Not COMPLETELY the case. It basically, that the client doesn't trust the network between itself and the STS and/or it doesn't trust the normal keys/certs. Basically, it wants to make sure the SAML assertion is not written on the wire in plain text or encrypted using a key that someone else would know. > > STS encrypts the SAML token using the clients public key and client > > decrypts the SAML token using it's own private key. > > But it seems that the CXF demo actually uses the Service's certificate > (i.e. Bob) instead of the Client certificate (Alice) to decrypt the SAML > key. In the case of the WS-Trust stuff with the KeyValueToken, it doesn't really matter what the key is. The client sends a public key, the server uses it without looking at it at all. In fact, the MS online "test" clients don't send the bob or alice keys. They actually generate a fresh key on the fly for this communication. If you invoke the test client twice, you'll get a completely new RSAKeyValue each time. Ideally, we'd update the configs to somehow allow this as well. That would be the ultimate in security for this case. For example, right now, if someone had bob/alices certs, they could decrypt the message. However, with MS's clients, ONLY the client that issues the request would have any chance of decrypting it. > And that begs the question, why does the client need to decrypt the > SAML token? The client is the only one that has the private key that is capable of decrypting it to even know if it's a SAML token. If it was passed as is to the server, the server wouldn't have the key or anything to decrypt it or process it or anything. > I thought the SAML token is mean to be consumed by the remote > Service. That is, the client could treat the SAML token as an opaque blob > and just forward it on to the Service. -- Daniel Kulp [email protected] http://www.dankulp.com/blog
