You are viewing a plain text version of this content. The canonical link for it is here.

Posted to wss4j-dev@ws.apache.org by Siarhei Kaneuski <Si...@epam.com> on 2010/01/26 19:46:54 UTC

Optional encryption/decryption

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.java:505)
        at org.apache.ws.security.message.WSSecEncrypt.doEncryption(WSSecEncrypt.java:459)
        at org.apache.ws.security.message.WSSecEncrypt.encryptForInternalRef(WSSecEncrypt.java:348)
        at org.apache.ws.security.message.WSSecEncrypt.build(WSSecEncrypt.java:309)
        at org.apache.ws.security.action.EncryptionAction.execute(EncryptionAction.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(WSS4JInInterceptor.java:219)
        at org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessage(WSS4JInInterceptor.java:77)
        at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:236)
        at org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:658)
        at org.apache.cxf.transport.local.LocalDestination$SynchronousConduit$1$1.run(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

RE: Optional encryption/decryption

Posted by Siarhei Kaneuski <Si...@epam.com>.

Hi Dan,

Thank you for pointing out WS-SecurityPolice option. I need some time to dive in it, it's definitely more complicated than wss4j interceptors configurations. 

Thanks,
Siarhei


-----Original Message-----
From: Daniel Kulp [mailto:dkulp@apache.org] 
Sent: Thursday, January 28, 2010 4:10 PM
To: users@cxf.apache.org
Cc: wss4j-dev@ws.apache.org; Siarhei Kaneuski; Werner Dittmann
Subject: Re: Optional encryption/decryption


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-unsubscribe@ws.apache.org
> > >> For additional commands, e-mail: wss4j-dev-help@ws.apache.org
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: wss4j-dev-help@ws.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: wss4j-dev-help@ws.apache.org
> 

-- 
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog

---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org

RE: Optional encryption/decryption

Posted by Siarhei Kaneuski <Si...@epam.com>.

Hi Dan,

Thank you for pointing out WS-SecurityPolice option. I need some time to dive in it, it's definitely more complicated than wss4j interceptors configurations. 

Thanks,
Siarhei


-----Original Message-----
From: Daniel Kulp [mailto:dkulp@apache.org] 
Sent: Thursday, January 28, 2010 4:10 PM
To: users@cxf.apache.org
Cc: wss4j-dev@ws.apache.org; Siarhei Kaneuski; Werner Dittmann
Subject: Re: Optional encryption/decryption


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-unsubscribe@ws.apache.org
> > >> For additional commands, e-mail: wss4j-dev-help@ws.apache.org
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: wss4j-dev-help@ws.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: wss4j-dev-help@ws.apache.org
> 

-- 
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog

Re: Optional encryption/decryption

Posted by Daniel Kulp <dk...@apache.org>.

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-unsubscribe@ws.apache.org
> > >> For additional commands, e-mail: wss4j-dev-help@ws.apache.org
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: wss4j-dev-help@ws.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: wss4j-dev-help@ws.apache.org
> 

-- 
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog

---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org

Re: Optional encryption/decryption

Posted by Daniel Kulp <dk...@apache.org>.

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-unsubscribe@ws.apache.org
> > >> For additional commands, e-mail: wss4j-dev-help@ws.apache.org
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: wss4j-dev-help@ws.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: wss4j-dev-help@ws.apache.org
> 

-- 
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog

RE: Optional encryption/decryption

Posted by Hannes Angst <ha...@googlemail.com>.

You can catch the exception anyway, and check whether it was thrown because of 
a missing enc.




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(WSSecE
> >>ncrypt.java:348) at
> >> org.apache.ws.security.message.WSSecEncrypt.build(WSSecEncrypt.java:309)
> >> at
> >> org.apache.ws.security.action.EncryptionAction.execute(EncryptionAction.
> >>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(WSS4JI
> >>nInterceptor.java:219) at
> >> org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessage(WSS4JI
> >>nInterceptor.java:77) at
> >> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorC
> >>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-unsubscribe@ws.apache.org
> >> For additional commands, e-mail: wss4j-dev-help@ws.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: wss4j-dev-help@ws.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: wss4j-dev-help@ws.apache.org
>

-- 
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog

---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org

RE: Optional encryption/decryption

Posted by Hannes Angst <ha...@googlemail.com>.

You can catch the exception anyway, and check whether it was thrown because of 
a missing enc.




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(WSSecE
> >>ncrypt.java:348) at
> >> org.apache.ws.security.message.WSSecEncrypt.build(WSSecEncrypt.java:309)
> >> at
> >> org.apache.ws.security.action.EncryptionAction.execute(EncryptionAction.
> >>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(WSS4JI
> >>nInterceptor.java:219) at
> >> org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessage(WSS4JI
> >>nInterceptor.java:77) at
> >> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorC
> >>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-unsubscribe@ws.apache.org
> >> For additional commands, e-mail: wss4j-dev-help@ws.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: wss4j-dev-help@ws.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: wss4j-dev-help@ws.apache.org
>

-- 
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog

---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org

Re: Optional encryption/decryption

Posted by Daniel Kulp <dk...@apache.org>.

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(WSSecE
> >>ncrypt.java:348) at
> >> org.apache.ws.security.message.WSSecEncrypt.build(WSSecEncrypt.java:309)
> >> at
> >> org.apache.ws.security.action.EncryptionAction.execute(EncryptionAction.
> >>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(WSS4JI
> >>nInterceptor.java:219) at
> >> org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessage(WSS4JI
> >>nInterceptor.java:77) at
> >> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorC
> >>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-unsubscribe@ws.apache.org
> >> For additional commands, e-mail: wss4j-dev-help@ws.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: wss4j-dev-help@ws.apache.org
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: wss4j-dev-help@ws.apache.org
> 

-- 
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog

Re: Optional encryption/decryption

Posted by Daniel Kulp <dk...@apache.org>.

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(WSSecE
> >>ncrypt.java:348) at
> >> org.apache.ws.security.message.WSSecEncrypt.build(WSSecEncrypt.java:309)
> >> at
> >> org.apache.ws.security.action.EncryptionAction.execute(EncryptionAction.
> >>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(WSS4JI
> >>nInterceptor.java:219) at
> >> org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessage(WSS4JI
> >>nInterceptor.java:77) at
> >> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorC
> >>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-unsubscribe@ws.apache.org
> >> For additional commands, e-mail: wss4j-dev-help@ws.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: wss4j-dev-help@ws.apache.org
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: wss4j-dev-help@ws.apache.org
> 

-- 
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog

---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org

Re: Optional encryption/decryption

Posted by Siarhei Kaneuski <si...@epam.com>.

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.java:505)
>>          at org.apache.ws.security.message.WSSecEncrypt.doEncryption(WSSecEncrypt.java:459)
>>          at org.apache.ws.security.message.WSSecEncrypt.encryptForInternalRef(WSSecEncrypt.java:348)
>>          at org.apache.ws.security.message.WSSecEncrypt.build(WSSecEncrypt.java:309)
>>          at org.apache.ws.security.action.EncryptionAction.execute(EncryptionAction.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(WSS4JInInterceptor.java:219)
>>          at org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessage(WSS4JInInterceptor.java:77)
>>          at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:236)
>>          at org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:658)
>>          at org.apache.cxf.transport.local.LocalDestination$SynchronousConduit$1$1.run(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-unsubscribe@ws.apache.org
>> For additional commands, e-mail: wss4j-dev-help@ws.apache.org
>>      
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: wss4j-dev-help@ws.apache.org
>
>    


---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org

Re: Optional encryption/decryption

Posted by Werner Dittmann <We...@t-online.de>.

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.java:505)
>         at org.apache.ws.security.message.WSSecEncrypt.doEncryption(WSSecEncrypt.java:459)
>         at org.apache.ws.security.message.WSSecEncrypt.encryptForInternalRef(WSSecEncrypt.java:348)
>         at org.apache.ws.security.message.WSSecEncrypt.build(WSSecEncrypt.java:309)
>         at org.apache.ws.security.action.EncryptionAction.execute(EncryptionAction.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(WSS4JInInterceptor.java:219)
>         at org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessage(WSS4JInInterceptor.java:77)
>         at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:236)
>         at org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:658)
>         at org.apache.cxf.transport.local.LocalDestination$SynchronousConduit$1$1.run(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-unsubscribe@ws.apache.org
> For additional commands, e-mail: wss4j-dev-help@ws.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org