Hi Davide, (I have replied to one of your earlier reply to mine). I found bunch of postings here and few blogs. Please look at ACEGI+ CAS (SSO) fro SSO.
Please refer to this great post, http://domagojtechtips.blogspot.com/2007/08/cxf-spring-and-ws-security-putting-it.html explains security prpogation. The idea is to tie in Acegi to this one and use Acegi+CAS for SSO. This post explains the ACEGI+CXF. http://www.nabble.com/Acegi-Security-with-CXF-tf4337860.html#a12391936 The answer is out there in bits and pieces, but they all need to be tied down! I have n't had a chance to tie'em together yet. If you are interested we can work together. After thanksgiving I will get to it! Any help will be appreciated! Thanks Matt Thkx again, the smoke is clearing out! The infrastructure I am working in is http transport based, but probably in the future will be moved to a JMS transport. So in the future I could not rely on HTTPS anymore... anyway now I have it! I haven't understood yout sentence "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 which sense? WS_Secure Conversation is implemented using Kerberos? Fred Dushin-3 wrote: > > 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. >> >> > > > -- View this message in context: http://www.nabble.com/WS-Security-Single-Sign-On-tf4429137.html#a13902529 Sent from the cxf-user mailing list archive at Nabble.com.
