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: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
