Hallo Mayank, The first part of your explanation makes a lot of sense. But I still have trouble understanding the second bit. See replies below...
Mayank Mishra-3 wrote: > > Hi, > Very Interesting! I looked into the conversation between the client and > the STS. You can look in the first outbound message from client (client > to STS for requesting the saml token) that the <keytype> in the RST > element is of type "public key". > > 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 > (RequestSecurityToken) message client supplies RSA key or X.509 public > key to STS. STS just embeds the RSA key or X.509 public key certificate > in the /<keyinfo>/ element of the /<subjectconfirmation>/ element in the > issued SAML assertion in the RSTR response to the client. Client then > forward the issued SAML assertion to the service. > Thanks for this clear explanation, Mayank! Mayank Mishra-3 wrote: > > 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. And that begs the question, why does the client need to decrypt the SAML token? 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. Cheers, Fintan -- View this message in context: http://www.nabble.com/Understanding-the-WS-Trust-client-tp24204404p24216461.html Sent from the cxf-user mailing list archive at Nabble.com.
