Actually, when I thought about this some more, with the WS-SecurityPolicy
route, you can tag the policies as optional. Thus, the policies on the
incoming side wouldn't need to be asserted as they'd be completely optional.
Dan
On Wed January 27 2010 5:44:40 pm Daniel Kulp wrote:
> One "option" that I think might work for CXF would be to switch from using
> the WSS4JIn/Out things to using the WS-SecurityPolicy based
> implementation. I THINK the XPath based stuff in the CXF
> WS-SecurityPolicy are in a "if the element exists, do this" type form.
> Thus, if you use an XPath to the credit card element, if it's not sent, it
> wouldn't get encrypted.
>
> I don't think that completely solves the incoming "security header doesn't
> exist" issue though. Without that header, I don't think any of the
> policies would be asserted. Probably would still need an interceptor to
> work around that issue. :-(
>
> Dan
>
> On Wed January 27 2010 4:09:54 pm Siarhei Kaneuski wrote:
> > Hi Werner,
> >
> > First of all, thank you for clarification. The behavior was designed in
> > this way - I get it.
> >
> > What WSS4J could do (when cannot find encryption part, or key in header)
> > - well, I agree, it should fail by default 'cause that seems to be the
> > most frequent use case of the framework. My point there was - the
> > behavior could be configurable in some way. I'm working on real-world
> > scenario (see the beginning of my original mail), and for this scenario
> > optional encryption makes sense IMO (to support existing clients unaware
> > of encryption introduced for new response parts etc.). For me, it is
> > especially important for point 1 - I have to store encryption part in
> > ThreadLocal storage (and then pick it in out interceptor) any time
> > service decides to use credit card in response. What do you think?
> >
> > Thanks again,
> > Siarhei
> >
> > On 01/27/2010 08:07 PM, Werner Dittmann wrote:
> > > Hi,
> > >
> > > without knowing CFXY and how it works I know a bit of WSS4J and
> > > the security behind the OASIS specs.
> > >
> > > as for point 1:
> > > If WSS4J does not find the specified element it reports an error.
> > > This is by desing. What else should it do? Silently ignoring this
> > > could mean that a possible typo in the deployment is not detected
> > > and some data goes unencrypted over the wire.
> > >
> > > as for point 2:
> > > If the security header contains an encryption key then WSS4j also
> > > throws an error. A missing key could mean that someone tampered
> > > with the security header or it was a problem during transmission.
> > >
> > > Anyhow: performing "optional" encryption depending on existent or
> > > missing data is a security problem. Either all mecessary information
> > > is available for encryption/decryption or nothing will happen at all.
> > >
> > > Regards,
> > > Werner
> > >
> > > Am 26.01.2010 19:46, schrieb Siarhei Kaneuski:
> > >> Hi everyone,
> > >>
> > >> I'm working on implementation of CXF service managing user profiles
> > >> (which may contain sensitive data - credit card number, ID number).
> > >> There are some profiles containing the sensitive data, and some which
> > >> don't. Even more, the service can work in mode when no sensitive data
> > >> will be sent to consumer. Naturally, I'd like to make
> > >> encryption/decryption optional:
> > >>
> > >> * Do not encrypt anything if nothing from encryptionParts is
> > >> found (on service)
> > >>
> > >> * Do not decrypt anything if no encryption key found in
> > >> WS-Security header (on client)
> > >>
> > >>
> > >> 1. Do not encrypt anything if nothing from encryptionParts is
> > >> found. When my endpoint is configured in the following way, and I
> > >> don't put real value to element from encryptionParts, out processing
> > >> fails: <bean id="serviceOutSecurityInterceptor" class="com
> > >> org.apache.cxf.ws.security.wss4j.WSS4JOutInterceptor">
> > >> <constructor-arg> <map>
> > >> <entry key="action" value="Encrypt" />
> > >> <entry key="encryptionPropFile"
> > >> value="serviceKeystore.properties" /> <entry key="encryptionParts"
> > >> value="{Element}{http://test.com/sample/service}text"; /> <entry
> > >> key="encryptionUser" value="myClientKey" />
> > >> </map>
> > >> </constructor-arg>
> > >> </bean>
> > >>
> > >> Caused by: org.apache.ws.security.WSSecurityException: General
> > >> security error (WSEncryptBody/WSSignEnvelope: Element to encrypt/sign
> > >> not found: {http://test.com/sample/service}text) at
> > >> org.apache.ws.security.message.WSSecEncrypt.doEncryption(WSSecEncrypt.
> > >>ja va:505) at
> > >> org.apache.ws.security.message.WSSecEncrypt.doEncryption(WSSecEncrypt.
> > >>ja va:459) at
> > >> org.apache.ws.security.message.WSSecEncrypt.encryptForInternalRef(WSSe
> > >>cE ncrypt.java:348) at
> > >> org.apache.ws.security.message.WSSecEncrypt.build(WSSecEncrypt.java:30
> > >>9) at
> > >> org.apache.ws.security.action.EncryptionAction.execute(EncryptionActio
> > >>n. java:62) ... 10 more
> > >>
> > >> As I see from code, there is no good way to configure WSS4J to ignore
> > >> missing encryption parts (at least, in WSS4J 1.5.8 which I use). Is
> > >> that by design? Do you have any suggestions how to handle such
> > >> situations? I have workaround for it - when service actually has
> > >> something to encrypt, it puts a encryption part to ThreadLocal, and
> > >> then my interceptor overriding WSS4JOutInterceptor decides add Encrypt
> > >> action or not (see attachment). Looks awkward.
> > >>
> > >>
> > >> 2. Do not decrypt anything if no encryption key found in
> > >> WS-Security header. Client can get response with encrypted parts, but
> > >> also can get plain message w/o WS-Security header. <bean
> > >> id="clientInSecurityInterceptor"
> > >> class="org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor">
> > >> <constructor-arg>
> > >> <map>
> > >> <entry key="action" value="Encrypt" />
> > >> <entry key="passwordCallbackRef">
> > >> <ref bean="clientCallback" />
> > >> </entry>
> > >> <entry key="decryptionPropFile"
> > >> value="clientKeystore.properties" /> </map>
> > >> </constructor-arg>
> > >> </bean>
> > >>
> > >> Fails:
> > >> org.apache.ws.security.WSSecurityException: An error was discovered
> > >> processing the<wsse:Security> header at
> > >> org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessage(WSS4
> > >>JI nInterceptor.java:219) at
> > >> org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessage(WSS4
> > >>JI nInterceptor.java:77) at
> > >> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseIntercepto
> > >>rC hain.java:236) at
> > >> org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:658) at
> > >> org.apache.cxf.transport.local.LocalDestination$SynchronousConduit$1$1
> > >>.r un(LocalDestination.java:97) at
> > >> java.lang.Thread.run(Thread.java:619)
> > >>
> > >> Do I understand correctly the behavior is not configurable? WSS4J just
> > >> looks for security header and fails when nothing found. To workaround
> > >> that, I had to override WSS4JInInterceptor, and enable Encrypt action
> > >> (which actually decrypts) when WS-Security header found. Again, it's
> > >> weird - see attachment (I like most the part accessing SOAPMessage -
> > >> instantiating SAAJInInterceptor because of lack of access to private
> > >> method in WSS4JInInterceptor).
> > >>
> > >> I'd appreciate if anybody commented: was the behavior described above
> > >> designed in that way? Are there any good way to implement/workaround
> > >> that? If not, any suggestions on code attached?
> > >>
> > >> Thanks,
> > >> Siarhei
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: wss4j-dev-unsubscr...@ws.apache.org
> > >> For additional commands, e-mail: wss4j-dev-h...@ws.apache.org
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: wss4j-dev-unsubscr...@ws.apache.org
> > > For additional commands, e-mail: wss4j-dev-h...@ws.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: wss4j-dev-unsubscr...@ws.apache.org
> > For additional commands, e-mail: wss4j-dev-h...@ws.apache.org
>
--
Daniel Kulp
dk...@apache.org
http://www.dankulp.com/blog
