David,
WSS4J may have some recently added support for propagating kerberos
"tokens" (and by "token", I take it you mean a kerberos AP_REQ
message), but getting a token from point A to point B is a small
fraction of the story, when it comes to kerberos integration with Web
Services.
Yes, WS-SecureConversation is the route to take here, but a lot of
infrastructure needs to be put into place, in order to make effective
use of the Kerberos authentication protocol. In particular, security
sessions need to be established and maintained (along the lines of
abstractions provided by the GSS-API), and used to provide
cryptographic services for messages delivered in the secure channel
established.
Of course, this may be overkill. An alternative is to use SSL to
protect the channel, and just pass kerberos tickets as cookies. You
at least get some assurance of client identity that way, but that's a
pretty weak security story, IMO. It also requires that you use SSL,
which sort of defeats the purpose of using Kerberos, in the first
place -- or at a minimum overlooks the full power of the kerberos
infrastructure. SSL may not be a viable options for all deployments,
as well (e.g., JMS), but that doesn't seem to be an obstacle in your
specific case.
-Fred
On Sep 13, 2007, at 4:07 AM, Davide Gesino wrote:
Hi Fred,
With "Single Sign On" I meant a mechanism to have a series of messages
authenticated only once (with the first of the series) and treated
as a
conversation, instead of autenthicate each message.
I some way I would want to emulate something similar to initial login
followed by and exchange of messages.
Maybe this pertains the WS-SecureConversation specification, that
I've seen
will be covered in CXF 2.1.
There is a way to use Kerberos authentication token in wss4j ?!
David
Fred Dushin-3 wrote:
No question is silly or bad.
CXF itself provides no single sign-on capabilities, though one could
certainly try to implement one over CXF.
The challenge is to do it in a way that provides reasonable assurance
and protection from replay and man-in-the-middle attacks. The naive
approach is to grant the client a "cookie" in virtue of a login
event, and then for the client to present that cookie as "evidence"
of its identity. This way, the client is just using an opaque token
in lieu of otherwise sensitive security information. (I presume this
is what you mean by "single sign-on"). To do this, you need to lock
down your communications channels, presumably in your case, using
SSL. And you need to ensure that the dispensed cookies can't be
stolen or hijacked. That's a lot of trust you need to place in how
you deploy your infrastructure, and it only gets you so far.
The more compelling solution (IMO) is to use SSO technologies that
are already out there, such as Kerberos (which is arguably the most
deployed SSO solution going). But I'm guessing that's not what
you're after.
-Fred
On Sep 12, 2007, at 9:04 AM, Davide Gesino wrote:
Hi,
may be a silly or bad question but....
there is a way to have a single sign on mechanism in CXF (in WS in
general)
or I have to check the user credentials each time for each message?
There is a way to estabilish something similar to the Http Session
between
WS client and server?!?
In my app I have CXF deployed on Tomcat and the transport is Http.
David
--
View this message in context: http://www.nabble.com/WS-Security-
Single-Sign-On-tf4429137.html#a12634942
Sent from the cxf-user mailing list archive at Nabble.com.
--
View this message in context: http://www.nabble.com/WS-Security-
Single-Sign-On-tf4429137.html#a12650564
Sent from the cxf-user mailing list archive at Nabble.com.
