Fintan Bolton wrote:
Hi,
I'm having a hard time getting to grips with WS-Trust in CXF. The
interoperability demo works just fine, but I find it difficult to understand
exactly what is going on.
The following properties don't seem to be documented anywhere on the CXF Web
site:
ws-security.signature.properties
ws-security.signature.properties.decrypt
So I had a peek at the source code to try and figure out what these
properties are for. I could not really figure out how the
ws-security.signature.properties.decrypt property is meant to be used. To be
specific, I need to talk about a particular scenario.
The scenario I am currently looking at is
Scenario_7_IssuedTokenOverTransport_UsernameOverTransport. Briefly, this
WS-Trust scenario has the following characteristics:
* Uses HTTPS transport.
* Client authenticates itself to STS using UsernameToken credentials.
* Client requests SAML token from STS.
* Client's certificate is Alice, STS certificate is WssIP, Service's
certificate is Bob.
* STS has the public key from the Service's certificate and the Service has
the public key from the STS certificate. [This is according to the scenario
description document from the WCF Interoperability Lab.]
In the client configuration, the ws-security.signature.properties.decrypt
property references Bob's PKCS#12 certificate (which includes both a public
key and a private key). As far as I can tell from the source code, the
client uses this certificate to decrypt the SAML token received from the
STS. Now if the STS has only got Bob's public key, the STS must be using
Bob's public key to encrypt the SAML token
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.
STS encrypts the SAML token using the clients public key and client
decrypts the SAML token using it's own private key.
With Regards,
Mayank
and that suggests that the client
is using Bob's *private* key to decrypt the SAML token.
This is where I get confused. In a real deployment, it seems to me that the
client would not have access to Bob's private key (it belongs to the remote
service). Have I interpreted the source code correctly?
Cheers,
Fintan
