Re: [GSOC][CXF-2738]Proposal for "Integration with ZooKeeper for location transparency and clustering/failover"

Hmmm, I wonder if we could get Kevin to implement a Secure Token Service for us (CXF-1940) instead, and if we could get Willem to mentor him for that as well. But ZooKeeper is also good. Glen willem.jiang wrote: > > Hi kevin, > > It's an interesting project, I'd like to be your mentor. > But

Using WS-Security UsernameToken to authenticate users and populate SecurityContexts

Hi I've been looking recently at extending the CXF WS-Security component such that a current UsernameToken could be used by custom interceptors to authenticate a user with the external security systems and, if possible, provide enough information for CXF to populate a SecurityContext [1] to be use

Re: Using WS-Security UsernameToken to authenticate users and populate SecurityContexts

Hi Sergey, needless to say, I really like this. Just ping me of course when you move to the JBossWS side of this topic to do the tests. Cheers Alessio Sergey Beryozkin wrote: Hi I've been looking recently at extending the CXF WS-Security component such that a current UsernameToken could be us

Re: Using WS-Security UsernameToken to authenticate users and populate SecurityContexts

Glen Mazza asks : Quote: "Higher level containers should be able to delegate to their own subsystems for authenticating a user and populating SecurityContext" I'm not clear on something, why can't that be done (or why would it be suboptimal/inconvenient for doing that) from the already provided C

Re: Using WS-Security UsernameToken to authenticate users and populate SecurityContexts

Sergey, be careful with your first reason--that of using the CallbackHandlers to *return* passwords, that's an old erroneous design apparently since fixed in WSS4J (https://issues.apache.org/jira/browse/WSS-183) that should not necessarily be used as a reason for doing what you're doing--that proc

Re: Using WS-Security UsernameToken to authenticate users and populate SecurityContexts

Glen, On Wed, Apr 7, 2010 at 5:12 PM, Glen Mazza wrote: > > Sergey, be careful with your first reason--that of using the > CallbackHandlers > to *return* passwords, that's an old erroneous design apparently since > fixed > in WSS4J (https://issues.apache.org/jira/browse/WSS-183) that should not

Re: Using WS-Security UsernameToken to authenticate users and populate SecurityContexts

typo, missed 'not' "I'm sorry but this does *not* sounds convincing." On Wed, Apr 7, 2010 at 5:22 PM, Sergey Beryozkin wrote: > Glen, > > > On Wed, Apr 7, 2010 at 5:12 PM, Glen Mazza wrote: > >> >> Sergey, be careful with your first reason--that of using the >> CallbackHandlers >> to *return* p

Re: Using WS-Security UsernameToken to authenticate users and populate SecurityContexts

Actually Glen, sorry for a speedy reply. Here are some more clarifications. Please have a look at the source of the AbstractWSS4JSecurityContextProviding interceptor. In a nutshell, it is a complex CallbackHandler which simply delegates the authentication to its subclass overriding createSubject m

Re: Using WS-Security UsernameToken to authenticate users and populate SecurityContexts

Glen, On Wed, Apr 7, 2010 at 5:12 PM, Glen Mazza wrote: > > Sergey, be careful with your first reason--that of using the > CallbackHandlers > to *return* passwords, that's an old erroneous design apparently since > fixed > in WSS4J (https://issues.apache.org/jira/browse/WSS-183) that should n

Re: Using WS-Security UsernameToken to authenticate users and populate SecurityContexts

Hi Glen On Wed, Apr 7, 2010 at 6:25 PM, Glen Mazza wrote: > > > Glen, > > > On Wed, Apr 7, 2010 at 5:12 PM, Glen Mazza wrote: > > > > > Sergey, be careful with your first reason--that of using the > > CallbackHandlers > > to *return* passwords, that's an old erroneous design apparently since >

RE: Using WS-Security UsernameToken to authenticate users and populate SecurityContexts

Sergey, I think this type of functionality would be very useful to a number of folks. I have built two similar capabilities for clients very recently using CXF and Spring Security. Based on the code provided below, I have several points that I would like to see addressed in a solution. 1) Archi

Soap 1.1 endpoint already registered on address

Hi All, To day i have upgraded my cxf version to 2.2.7. I have generated client and server stubs as earlier. And when i try to publish the service i am getting following exception, Exception in thread "main" javax.xml.ws.WebServiceException: java.lang.RuntimeException: Soap 1.1 endpoint already r

Re: [GSOC][CXF-2738]Proposal for "Integration with ZooKeeper for location transparency and clustering/failover"

Hi Glen, I'm sorry you are late, maybe we can wait for another student to apply this project next time :) Willem Glen Mazza wrote: Hmmm, I wonder if we could get Kevin to implement a Secure Token Service for us (CXF-1940) instead, and if we could get Willem to mentor him for that as well.