You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Fintan Bolton <fb...@progress.com> on 2009/06/25 16:33:33 UTC
Understanding the WS-Trust client
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 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
--
View this message in context: http://www.nabble.com/Understanding-the-WS-Trust-client-tp24204404p24204404.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: Understanding the WS-Trust client
Posted by Mayank Mishra <ma...@gmail.com>.
Thanks Dan for clarifying some doubts about WS-Trust.
With Regards,
Mayank
Daniel Kulp wrote:
> 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.
>>
>
>
Re: Understanding the WS-Trust client
Posted by Fintan Bolton <fb...@progress.com>.
Thanks, Dan! That's a very helpful reply. It'll probably take me a little
while to digest it fully.
I'll have to educate myself more about WS-Trust, but it's difficult to find
any in-depth articles about what goes on under the hood.
Cheers,
Fintan
--
View this message in context: http://www.nabble.com/Understanding-the-WS-Trust-client-tp24204404p24222675.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: Understanding the WS-Trust client
Posted by Daniel Kulp <dk...@apache.org>.
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
dkulp@apache.org
http://www.dankulp.com/blog
Re: Understanding the WS-Trust client
Posted by Fintan Bolton <fb...@progress.com>.
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.
Re: Understanding the WS-Trust client
Posted by Mayank Mishra <ma...@gmail.com>.
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
>
Re: Understanding the WS-Trust client
Posted by Fintan Bolton <fb...@progress.com>.
Oops! Sorry, I used the wrong property names in the original post. I meant to
say:
ws-security.sts.token.properties
ws-security.sts.token.properties.decrypt
See below the fold for the corrected posting.
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.sts.token.properties
> ws-security.sts.token.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.sts.token.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.sts.token.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 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
>
--
View this message in context: http://www.nabble.com/Understanding-the-WS-Trust-client-tp24204404p24204603.html
Sent from the cxf-user mailing list archive at Nabble.com.