On Thu June 4 2009 10:35:59 am bharath thippireddy wrote: > Thanks again for the detailed reply Dan.I will try the encryptionParts > options.Since we do not have the nonce support right now to avoid replay > attacks,is there an other standard way to pass in the usename and password > on each web service call other than the USERNAME TOKEN PROFILE.Just to let > you konow,we cant use signing as we have some issues with the wss4j > signatures alogorithms .
Well, I think the most "normal" way for just username/password things is basic-auth over https. Certainly the most interopable and highest performing as well. Digest auth would also be in there (now supported by CXF as well). Dan > > Thanks and regards, > Bharath > -----Original Message----- > From: Daniel Kulp [mailto:[email protected]] > Sent: Wednesday, June 03, 2009 4:02 PM > To: [email protected] > Cc: bharath thippireddy > Subject: Re: Securing User Name Token using CXF? > > On Wed June 3 2009 2:48:32 pm bharath thippireddy wrote: > > Thanks for the answers Dan.From the following post I see that using the > > UsernameToken header and encryption together with wss4j/cxf has issues. > > Are they resolved now. > > From that thread, I'm not really sure what the "issue" is. It looks like > it's mostly Fred being Fred. (Fred is incredibly paranoid) If the goal > is just to make sure the UsernameToken is encrypted with a particular key, > then it should work fine to not expose the password. Fred is also > concerned about about other attacks where someone takes the encrypted > element (and all the other relevant stuff from the security header) and > attaches it to a different soap "body". In that case, the attacker > doesn't need to know the password. Thus, to avoid that, you then start to > need signatures using a client cert, probably timestamps with nonces, > etc.... That's where Fred was going. > > > If yes will there be two password callbacks ,one for the > > keystore password and the other for the password in the usernametoken. > > Yep. > > > This post on X509 encryptiong usingCXF is interesting but does not use > > UserNameTokens > > > > http://www.jroller.com/gmazza/entry/implementing_ws_security_with_the > > > > Can you please point me to some CXF samples which use the x509 cert > > encryption or other wss4j-encryption methods which encrypt only the Soap > > Headers(usernametoken) . > > Well, one thought is to use SecurityPolicy, but that then loses your "apply > to global bus level" thing that you want as the SecurityPolicy stuff is > just wsdl based right now. (on my todo list to address) > > I THINK you can do it with another property to the WSS4J handlers: > > encryptionParts={Element}{http://docs.oasis-op...........}UsernameToken > > > Dan > > > Thanks and regards, > > Bharath > > > > -----Original Message----- > > From: Daniel Kulp [mailto:[email protected]] > > Sent: Tuesday, June 02, 2009 3:57 PM > > To: [email protected] > > Cc: bharath thippireddy > > Subject: Re: Securing User Name Token using CXF? > > > > On Tue June 2 2009 3:06:52 pm bharath thippireddy wrote: > > > We are implementing User Name Token Profile for login on each web > > > service call to our application. Can you please answer the following > > > questions. > > > > > > > > > > > > 1)We use the cxf-servlet.xml file to configure our endpoints. Is there > > > a way to enable wss4j and username token profile callback functionality > > > at a global(BUS) level instead of adding the line below to each > > > endpoint. > > > > Yea. The "<cxf:bus>" element can be used to add the interceptors to the > > Bus itself. That will apply to all the endpoint on the bus. > > > > > 2) What is best recommended approach to secure the username and > > > password on each call? Is it HTTPS or are there other ways to do it > > > which are also interoperable? > > > > HTTPs would be the best performing. The other option is to fully use > > WS- Security and use an X509 cert to encrypt the UsernameToken header in > > the message. > > > > > > -- > > Daniel Kulp > > [email protected] > > http://www.dankulp.com/blog -- Daniel Kulp [email protected] http://www.dankulp.com/blog
