Hi Dan >>> Well, I guess it depends on who you are. If you are Microsoft, for ANY security related issues at all, they just send back a "Security token could not be processed" fault. No description at all as to why. >>> I fully understand this point of view and it makes absolut sense. The soap fault should not contain more information than something like the policies could not be satisfied. IMHO, we should not give more indication which underyling processing system detected a problem (like wss4j). On the server side it should be clear whether there is a problem with the policies or with the configuration of the server. A generic policy exception should be thrown if the policy expression could not be satisfied and returned back to the client. If CXF has been configured differently - without WS-SecurityPolicy, only plain WSS4J - we can give the wss4j message back - as it does now. What do you think? Thanks Oliver ________________________________
Von: Daniel Kulp [mailto:[email protected]] Gesendet: Di 20.10.2009 17:08 An: [email protected] Cc: Oliver Wulff Betreff: Re: AW: AW: WS-SecurityPolicy, UsernamePassword example On Tue October 20 2009 7:01:57 am Oliver Wulff wrote: > Hi Dan > > Changed my pom to 2.2.5-SNAPSHOT: > <properties> > <cxf.version>2.2.5-SNAPSHOT</cxf.version> > </properties> > > I can confirm that both issues are fixed. No exception on the client side > (CXF-2480) and when I remove the IncludeToken attribute (CXF-2479), I > don't get an exception either. My server starts successfully (which he > didn't before) and the client can successfully call him. Cool. Good news! > One question remain: I've sent a soap request without the username token > (from soapui). I'd expect that CXF throws a policy exception but it went > down to the WSS4JInInterceptor till the problem has been discovered. Is > this intended? > > [INFO] 20.10.2009 12:57:49 > org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor handleMessage [INFO] > WARNUNG: Request does not contain required Security header Well, I guess it depends on who you are. If you are Microsoft, for ANY security related issues at all, they just send back a "Security token could not be processed" fault. No description at all as to why. I guess it's to hinder hackers attempts to figure out what they need to adjust before trying again or something. However, from an testing/debugging standpoint, a huge pain in the butt to figure out what is wrong unless you have access to server logs. In any case, in the absence of a Security header at all, WSS4J returns a null result vector. If there is supposed to be one there (precomputed), we punt immediately. Otherwise, we'd need to guard against NullPointers and such all over. (or create a fake empty vector) Basically, it's faster (less processing) and easier, but I could easily be convinced it should be the other way. Thoughts? -- Daniel Kulp [email protected] http://www.dankulp.com/blog
