Hi, I've fixed the NPE in WSS4J. Yes, there is an asymmetry for the SAML case between the outbound and inbound configurations. This is mainly for historical reasons, not to break backwards compatibility with older deployments. On the outbound side, the "Unsigned" action just creates a SAML Token and adds it "as is" to the security header of the request. However, if the configuration states to sign the assertion, the assertion is internally signed. For the "Signed" SAML Action, it externally signs the assertion. On the receiving side, the "Signed SAML Action" matches either the internally or externally signed assertion use-cases.
Colm. On Mon, Apr 7, 2014 at 8:47 PM, chaij <jin.c...@indigoarc.com> wrote: > That's it! I am able to get the validation disabled. > Then I ran into this interesting issue. > > For client, wss4jOutInterceptor, I have to use SAMLTokenUnsigned action. If > I use SAMLTokenSigned instead, I would get a null pointer exception like > this: > java.lang.NullPointerException > at > > org.apache.ws.security.saml.WSSecSignatureSAML.prepare(WSSecSignatureSAML.java:262)[159:org.apache.ws.security.wss4j:1.6.12] > at > > org.apache.ws.security.saml.WSSecSignatureSAML.build(WSSecSignatureSAML.java:117)[159:org.apache.ws.security.wss4j:1.6.12] > at > > org.apache.ws.security.action.SAMLTokenSignedAction.execute(SAMLTokenSignedAction.java:99)[159:org.apache.ws.security.wss4j:1.6.12] > at > > org.apache.ws.security.handler.WSHandler.doSenderAction(WSHandler.java:232)[159:org.apache.ws.security.wss4j:1.6.12] > at > > org.apache.cxf.ws.security.wss4j.WSS4JOutInterceptor.access$200(WSS4JOutInterceptor.java:52)[162:org.apache.cxf.cxf-rt-ws-security:2.7.7] > at > > org.apache.cxf.ws.security.wss4j.WSS4JOutInterceptor$WSS4JOutInterceptorInternal.handleMessage(WSS4JOutInterceptor.java:260)[162:org.apache.cxf.cxf-rt-ws-security:2.7.7] > > For the server, wss4jInInterceptor, I have to use action SAMLTokenSigned. > Otherwise, I would get WSSecurityException. > 21:16:16,817 | WARN | p1389339194-1480 | ecurity.wss4j.WSS4JInInterceptor > 362 | 162 - org.apache.cxf.cxf-rt-ws-security - 2.7.7 | Security processing > failed (actions mismatch) > 21:16:16,818 | WARN | p1389339194-1480 | ecurity.wss4j.WSS4JInInterceptor > 335 | 162 - org.apache.cxf.cxf-rt-ws-security - 2.7.7 | > org.apache.ws.security.WSSecurityException: An error was discovered > processing the <wsse:Security> header > at > > org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.checkActions(WSS4JInInterceptor.java:363)[162:org.apache.cxf.cxf-rt-ws-security:2.7.7] > at > > org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessage(WSS4JInInterceptor.java:290)[162:org.apache.cxf.cxf-rt-ws-security:2.7.7] > at > > org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessage(WSS4JInInterceptor.java:95)[162:org.apache.cxf.cxf-rt-ws-security:2.7.7] > > > By looking at the wss4j interceptor code, on the server side, it looks for > if there is signature in the Assertion to determine if it is Signed or > Unsigned. But I don't know why exactly it is throwing NullPointer exception > on the client side. > > Thanks! > > > > > -- > View this message in context: > http://camel.465427.n5.nabble.com/add-SAML-TOKEN-to-SOAP-header-tp5749520p5749914.html > Sent from the Camel - Users mailing list archive at Nabble.com. > -- Colm O hEigeartaigh Talend Community Coder http://coders.talend.com
