Davide, There are lot of sample code out there for Acegi+CAS. I had my Acegi+CAS working more than a year ago.
The idea is to make them all together. As for as Authentcation using CXF+Acegi there are multiple posts withing this forms. Look for the one Anne Racel. I have not seen any imlementation on how to propogate the security token (Except may be one post for XFire and I have not understood it at all), between ws requests. Thanks Matt Davide Gesino wrote: > > Hi Matt, > > thanks for the links. > At the moment I'm trying to figure out how Sun project Metro manages WS-* > extensions. > Metro already supports this specs... > Anyway everything is hidden away from the developer from Netbeans IDE > (that still have some bugs). > It is not clear what 's going on behind the scenes in glassfish, metro and > netbeans. > expecially the transport is not pluggable, from thw wizard, so I have > chose the eclipse + CXF way to have more control on what I am doing. > My prj is based on CXF. > > going back to CXF... > Using an overall trusted Security Token Service (STS) that generates > security session tokens seems to be the right way to have a single signed > on (and then have a secure conversation). > Pls refer to: https://wsit.dev.java.net/docs/trust-whitepaper.pdf > CAS seems to be the way to provide a STS both client and server trust > I'm trying to understand how it works, how it could be integrated in > TOMCAT with CXF and ACEGI. > I have not still understood if CAS is protocol agnostic, I would not have > to rely upon HTTP transport security. > I'll try make something out all these technoligies, when I have some code > that does work (I hope) I'll make you know! > > > > > mattmadhavan wrote: >> >> 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#a13913861 Sent from the cxf-user mailing list archive at Nabble.com.
