On 10/14/2013 04:38 PM, Dennis Sosnoski wrote:
And now that I've had some sleep I'll modify my earlier retraction.
Metro, at least, does provide a way of doing the server certificate
distribution in WSDL, but through the WS-Addressing EndpointReference
rather than through the policy:
https://blogs.oracle.com/SureshMandalapu/entry/support_of_endpoint_references_with
Wow. Impressive find. Locating anything migrated over from the old Sun
blogs to their Oracle equivalent is no small feat!
That does sound indeed like another solution to my problem, but as you
say, it's non-standard, and involves wide publication
of the server cert, so it's off my list. I need something standard and
distributing the server cert only to clients that the WS runtime has
previously validated using the STS signature.
The bad news is that it looks like this is based on a non-standard
called "Web Services Addressing Identity", one of the many WS-*
technologies that was introduced but has never made it through to
become widely supported. It looks like this is the proposal:
http://schemas.xmlsoap.org/ws/2004/08/addressing/addressingidentity/WS-AddressingAndIdentity.pdf
An OASIS technical committee was set up to handle work in this area,
but it looks like they haven't actually produced anything:
https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=imi
Actually, reading the comments on that elderly blog, it looks like there
are some problems with the Metro specific implementation, circa 2011,
down in the SecurityClientTube. I myself have run into problems down in
that SecurityClientTube myself recently, whereby it didn't respect a
timestampTimeout attribute in the Sun specific WSIT policy. I wonder
how much sunlight that SecurityClientTube code gets these days.
I don't think CXF supports this particular non-standard, so it's
irrelevant to Susan's needs, but it is an interesting idea. Clients
need to have access to the WSDL anyway, so why not include the server
certificate directly in the WSDL? There are obvious security issues
involved which mean you wouldn't want to use this approach for
highly-secure services, but the advantage of configuration-free client
operation would be significant for services using certificates issued
by public CAs.
As you say, it is an interesting idea to put the cert in the WSDL
directly. But my Barbie Dream Secure Token Service would still be able
to support a mechanism whereby
->WSDLs have policy that say "Server certificate goes here",
->server runtime injects the certificate into the response as a header
->The STS receives header information and signs it
->the whole response with signed header goes back to the client,
->client runtime validates the header signed by the STS with the server
cert
->all is good so the client processes the response.
And I'm ever more convinced there is no way to do this in a standard way
that CXF, Metro and .NET would all support
*****
Thanks again for the responses to my questions, Dennis and Colm. You've
really helped me understand my problem better. Based on all I've come
to understand in the last few days, I've decided to punt the use of
WS-Trust for now. I'd sold it to my colleagues as possibly solving our
certificate problems. But because it doesn't, I think I'm going to leave
well enough alone for now, and stick to the WS-Security devil policy. we
already understand. In fact, one of my colleagues had an interesting
point - it is easier to remember to put the client certs in the server
truststore, and the server certs in the client truststore, which doesn't
happen all that often than to re-derive which trust store you DON'T have
to manipulate :-)
I appreciate the followup, Dennis.
Susan
