I am trying to implement a SAML Request Assertion Consumer Service (RACS) with Apache CXF 2.7.7
Unfortunately the response of my Identity Provider does not include a keyInfo (which is defined optional in the SAML specification).
This leads to an exception when processing the response, because CXF tries to load a DOM for the keyInfo.
java.lang.NullPointerException
at org.apache.ws.security.saml.ext.AssertionWrapper.verifySignature(AssertionWrapper.java:536)
I have a valid keystore.properties file as well as the certificate on my RACS site, but this does not chage the behaviour. Is this a bug in CXF or did I miss something to set up for my RACS?
After discussing this problem in the CXF Mailing List, we found out, that it is a bug in CXF Framework. A new issue was created here
Sending the KeyInfo in a SAML Request is optional (see Specification Section 5.4.5).
Currently there is no easy workaround available.
Related
I am using Spring SAML integration. I am getting below error when I tried to SAML logout without SingleLogout point.
I override the SAML method to check metadata has any SingleLogout point or not but it's not working.
Caused by: org.opensaml.saml2.metadata.provider.MetadataProviderException: IDP doesn't contain any SingleLogout endpoints
at org.springframework.security.saml.util.SAMLUtil.getLogoutBinding(SAMLUtil.java:108)
at org.springframework.security.saml.websso.SingleLogoutProfileImpl.sendLogoutRequest(SingleLogoutProfileImpl.java:66)
at org.springframework.security.saml.SAMLLogoutFilter.processLogout(SAMLLogoutFilter.java:140)
To properly override the lack of single logout endpoint in the metadata, you'd have to provide your own implementation of org.springframework.security.saml.websso.SingleLogoutProfile and inject it as a dependency in your application config. Certainly doable but quite a bit of effort for a problem that has a simpler solution: manually modify the metadata you received from the IdP and add the endpoint. (If the metadata is signed, you'll need to remove the signature).
Kentor - Using the SampleMvcApplication with success through their StubIdp but when I try with Clareity I receive the above error.
Without knowing anything about the implementations ( Kentor, SampleMvcApplication, StubIdP, Clareity )it looks as if:
Your Identity Provider implementation does not return a 'RelayState' parameter in the body of the HTTP POST along with the SAMLResponse.
Your Identity Provider implementation has added an InResponseTo attribute in the SAMLResponse element
Your Service Provider implementation interprets this as an IdP initiated SSO since it does not see a 'RelayState' parameter
Your Service Provider throws an error since it doesn't make sense for an SAMLResponse in an IdP initiated SSO flow to have an InResponseTo. InResponseTo refers to an AuthenticationRequest which is only there in a normal SP initiated SSO.
To get more help, you should tell us a little about the implementation you are using and your configuration.
I have an interceptor, for inbound responses to my client, that runs in the pre-logical phase of an apache cxf 2.7 jax-ws app. That interceptor logs the soap envelope body to a file as a string; no marshalling involved. When the request and response are fine, it works great. But when the response fails to pass schema validation, the interceptor does not create a new file. So I'm guessing the pre-logical phase happens after the schema validation but I have not found any good docs describing all the phases and order of processing. What is the phase just before schema validation? http://cxf.apache.org/docs/interceptors.html
Just now found this... http://www.mastertheboss.com/images/stories/ws/interceptors.png
I will also try to temporarily turn off schema validation for this client.
We're invoking a secured SOAP WebService using Camel CXF deployed in Fuse. In the client, we have configured TrustStore and Keystore as per the standard config. We're able to hit the server via Netscaler. The server is generating the response and sending it back to Netscaler.
When the response is received from Netscaler, it is encrypted and should be decrypted by Camel CXF. The decryption is not happening and on the client we get a parsing error since the response is all encrypted.
Any clues of what could be the problem ?
The only stackTrace that I see is that the message failed to parse because of the presence of Ctrl characters since the message is encrypted.
<http:conduit name="https.*">
<http:tlsClientParameters secureSocketProtocol="TLS">
<sec:keyManagers ref="keyManagersBean"/>
<sec:trustManagers ref="trustManagersBean"/>
</http:tlsClientParameters>
</http:conduit>
The keyManager and trustManager beans are created using a custom factory.
Also, could this issue be because apart from transport level encryption, we also need message level encryption ?
This problem was resolved. The issue was the the content was gzipped before being sent from NetScaler. Hence, after transport level decryption we could still see the headers but not the content. Adding a GZip in & fault interceptor on the CXF endpoint fixed the issue.
I don't know what I changed anymore :(... But I have ended up with this exception which I don't seem to solve:
Caused by: javax.xml.ws.soap.SOAPFaultException: A SOAP 1.2 message is not valid when sent to a SOAP 1.1 only endpoint.
I am using CXF 2.7.4 and have the classes generated from the wsdl.
I am using the MTOM and WSS4JOutInterceptor for signing outgoing messages.
The wsdl contains things like:
<wsdl:definitions ... xmlns:soap11="http ... >
<soap11:binding
<soap11:operation
soap11:address
So that all sound like soap 1.1, but somehow soap 1.2 is being used in the client for the created message.
I have added this in my jaxws client config, but it had no effect.
<jaxws:binding>
<soap:soapBinding version="1.1"/>
</jaxws:binding>
Why does CXF try to use soap 1.2 at all?
Please some advice on how to solve this?
- Ed
I think it is because incoming message is in SOAP1.2 format.
See if it contains references to namespace http://www.w3.org/2003/05