On 10/15/2013 12:24 AM, Dennis Sosnoski wrote:
...That still leaves you distributing server certificates to clients,
but you can always embed these in the policy and have the client load
that from a secure source (note that I haven't tried this with CXF,
but AFAIK it should work).
Sorry, I don't think there is any way of doing this. When I wrote the
original response I thought I'd seen it somewhere, but after looking
over the WS-SecurityPolicy specifications I think I was wrong. Too bad -
it would be great to have a way to avoid distributing server
certificates to clients.
- Dennis
- Dennis
Dennis M. Sosnoski
Java SOA and Web Services Consulting
<http://www.sosnoski.com/consult.html>
CXF and Web Services Security Training
<http://www.sosnoski.com/training.html>
Web Services Jump-Start <http://www.sosnoski.com/jumpstart.html>
On 10/14/2013 11:46 PM, Susan Liebeskind wrote:
Folks,
Is there a way to write WS-SecurityPolicy for WS-Trust and/or use
WS-SecureConversation in Apache CXF, such that clients and servers
using an STS could be configured WITHOUT having to provide the server
X.509 certificate to the client for message level signing purposes?
One possible approach: the client-server shared symmetric key,
vouched for by an STS, and distributed in the incoming server request
in a signed SOAP header, could be used to provide signature
validation for the client when the response comes back from the server.
Alternatively, if there were a way that I could send the server
certificate back to the client, in a SOAP header signed by the STS,
that might work. I realize there would be the extra overhead of
another trip to the STS for the return trip but that might be
acceptable. This approach, if it exists, would parallel the way that
the client cert gets sent to the server for the request...but I've
not been able yet to figure out how to write WS-SecurityPolicy to do
this, and am not sure if this would work with a .NET client.
The third thought is that I might be trying to re-invent
WS-SecureConversation here. If WS-SecureConversation can be setup
such that I don't have to distribute client certs to servers AND
server certs to clients, that works for me.
----
My requirements are to use X.509 certificates for authentication and
apply message level signatures. I will also be using 2 way TLS for
messages sent between client and server. Those messages will pass
through XML appliances between client and server, for XML schema
validation of the payload. Therefore encryption will be at the transport
level, and not at the message level. If you were to look at the STS
overview diagram provided in the Redhat JBoss FuseSource
documentation (http://tinyurl.com/n7nor5n), that's basically my
setup, except I'm not encrypting at the message level.
Again, if there was some way I could avoid having to distribute
client certs to servers AND server certs to clients, by using such a
symmetric key, that would be great. But so far, I don't see a way
to get the signatures I need without putting server certs into client
truststores. To be sure, I am new to WS-Trust, and
WS-SecureConversation. However, I don't know if my lack of obvious
solutions is because of my newbie ignorance or because it just cannot
be done.
---
I'm looking more for guidance that a solution without manual
certificate distribution is possible - I don't spend a long time
trying to do something that isn't going to work.
Thanks in advance to the WS-Security gurus on this list who might be
able to say "Yes, this is doable" or "No, don't bother trying because
you cannot make it work" or "Try this instead"
Susan
