[jira] [Resolved] (CXF-2899) NPE in WSS4J due to null Cryptos when using ws-security.*.crypto instead of ws-security.*.properties

["Daniel Kulp (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/CXF-2899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Daniel Kulp resolved CXF-2899.
------------------------------

       Resolution: Cannot Reproduce
    Fix Version/s: Invalid
         Assignee: Daniel Kulp


Cannot reproduce with latest code and simple test case and more complete testcase not provided after over a year.

> NPE in WSS4J due to null Cryptos when using ws-security.*.crypto instead of ws-security.*.properties
> ----------------------------------------------------------------------------------------------------
>
>                 Key: CXF-2899
>                 URL: https://issues.apache.org/jira/browse/CXF-2899
>             Project: CXF
>          Issue Type: Bug
>          Components: Documentation
>    Affects Versions: 2.2.9
>         Environment: All apply, but this was discovered on 64bit Ubuntu
>            Reporter: Ravi Luthra
>            Assignee: Daniel Kulp
>             Fix For: Invalid
>
>
> Null pointer exception in the given stack trace (see below). Turns out the Crypto objects are null which is caused by a documentation issue on this page:
> http://cxf.apache.org/docs/ws-securitypolicy.html
> I originally implemented my properties at runtime (using Java code directly) by setting up the Crypto object directly (using the Merlin class) and used the properties on the above mentioned URL: ws-security.signature.crypto and ws-security.encryption.crypto. These properties work until the stack reaches into the WSS4J boundary. The fix was to use the properties ws-security.signature.properties and ws-security.encryption.properties as these are the ones considered during the hand-off to WSS4J, not the ws-security.*.crypto properties. The stack trace went away when I used the other properties.
> java.lang.NullPointerException
> 	at org.apache.ws.security.message.token.X509Security.getX509Certificate(X509Security.java:92)
> 	at org.apache.ws.security.processor.BinarySecurityTokenProcessor.getCertificatesTokenReference(BinarySecurityTokenProcessor.java:105)
> 	at org.apache.ws.security.processor.BinarySecurityTokenProcessor.handleToken(BinarySecurityTokenProcessor.java:81)
> 	at org.apache.ws.security.WSSecurityEngine.processSecurityHeader(WSSecurityEngine.java:326)
> 	at org.apache.ws.security.WSSecurityEngine.processSecurityHeader(WSSecurityEngine.java:243)
> 	at org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessage(WSS4JInInterceptor.java:208)
> 	at org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessage(WSS4JInInterceptor.java:78)
> 	at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:243)
> 	at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:110)
> 	at org.apache.cxf.transport.servlet.ServletDestination.invoke(ServletDestination.java:98)
> 	at org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:423)
> ... Unrelated portion of stack
> The fix I am asking for is a fix in the documentation next to the .crypto properties.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira