I am using
camel: 2.12.1
spring: 4.0.5.RELEASE
CXF : 2.7.13
My goal is to deliver a soap message with wsse:security header(as mentioned below) in Payload mode from my camel router to some endpoint.
<wsse:Security soapenv:mustUnderstand="1"
xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
<wsse:UsernameToken
wsu:Id="UsernameToken-D5896C4D7E4684BCF8141101393698197">
<wsse:Username><xsl:value-of select="User" /></wsse:Username>
<wsse:Password
Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText"><xsl:value-of select="password" /></wsse:Password>
<wsu:Created><xsl:value-of select="$START_TIME" /></wsu:Created>
</wsse:UsernameToken>
</wsse:Security>
To achieve this, I have created a config file which has the below entry
<jaxws:client name="{http://com.abc/CallingService}CallingService" createdFromAPI="true">
<jaxws:properties>
<entry key="ws-security.username" value= "User" />
<entry key="ws-security.password" value="password" />
</jaxws:properties>
</jaxws:client>
But not sure how can I use this file or call this somewhere in route or some other spring config file , so that I can have a soap header in my out going message.
I am currently getting the exception
org.apache.cxf.ws.policy.PolicyException: No username available
at org.apache.cxf.ws.security.wss4j.AbstractTokenInterceptor.policyNotAsserted(AbstractTokenInterceptor.java:229) ~[cxf-rt-ws-security-2.7.13.jar:2.7.13]
at org.apache.cxf.ws.security.wss4j.UsernameTokenInterceptor.addUsernameToken(UsernameTokenInterceptor.java:361) ~[cxf-rt-ws-security-2.7.13.jar:2.7.13]
at org.apache.cxf.ws.security.wss4j.UsernameTokenInterceptor.addToken(UsernameTokenInterceptor.java:307) ~[cxf-rt-ws-security-2.7.13.jar:2.7.13]
at org.apache.cxf.ws.security.wss4j.AbstractTokenInterceptor.handleMessage(AbstractTokenInterceptor.java:95) ~[cxf-rt-ws-security-2.7.13.jar:2.7.13]
at org.apache.cxf.ws.security.wss4j.AbstractTokenInterceptor.handleMessage(AbstractTokenInterceptor.java:61) ~[cxf-rt-ws-security-2.7.13.jar:2.7.13]
My wsdl's policy is as below:
<wsp:Policy wsu:Id="EndpointSecurityPolicy" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702">
<wsp:ExactlyOne>
<wsp:All>
<sp:TransportBinding>
<wsp:Policy>
<sp:TransportToken>
<wsp:Policy>
<sp:HttpsToken>
<wsp:Policy>
<sp:RequireClientCertificate/>
</wsp:Policy>
</sp:HttpsToken>
</wsp:Policy>
</sp:TransportToken>
<sp:AlgorithmSuite>
<wsp:Policy>
<sp:Basic128/>
</wsp:Policy>
</sp:AlgorithmSuite>
<sp:IncludeTimestamp/>
</wsp:Policy>
</sp:TransportBinding>
<sp:SupportingTokens>
<wsp:Policy>
<sp:UsernameToken>
<wsp:Policy>
<sp:NoPassword/>
</wsp:Policy>
</sp:UsernameToken>
</wsp:Policy>
</sp:SupportingTokens>
</wsp:All>
<wsp:All>
<sp:TransportBinding>
<wsp:Policy>
<sp:TransportToken>
<wsp:Policy>
<sp:HttpsToken>
<wsp:Policy/>
</sp:HttpsToken>
</wsp:Policy>
</sp:TransportToken>
<sp:AlgorithmSuite>
<wsp:Policy>
<sp:Basic128/>
</wsp:Policy>
</sp:AlgorithmSuite>
<sp:IncludeTimestamp/>
</wsp:Policy>
</sp:TransportBinding>
<sp:SupportingTokens>
<wsp:Policy>
<sp:UsernameToken>
<wsp:Policy>
<sp:WssUsernameToken11/>
</wsp:Policy>
</sp:UsernameToken>
</wsp:Policy>
</sp:SupportingTokens>
</wsp:All>
</wsp:ExactlyOne>
</wsp:Policy>
Any help or pointers?
maybe you need to add a PasswordCallbackHandler.
Related
We need to setup ADFS as a service provider. So, we tried to send saml response to ADFS. We configured stubs for claims provider, RPT and created certs. We try to send saml to adfs/ls/IdpinitiatedSignon.aspx with RelayState.
Here is Saml Response example.
<samlp:Response ID="_6bcc31a5-fcc2-46a6-a84d-0df2cb5bed17" Version="2.0" IssueInstant="2019-03-27T12:37:34.839Z" Destination="https://srv2012-test-dc.testdomain.com/adfs/ls/idpinitiatedsignon.aspx" InResponseTo="_728ac076-7b14-4ce2-8efb-ed5c8c9b85f3" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
<Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion">anthem.cn.com</Issuer>
<samlp:Status>
<samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
</samlp:Status>
<Assertion ID="_eeaaab87-0fcc-4ec1-93d3-ed623b27130c" IssueInstant="2019-03-27T12:37:41.843Z" Version="2.0" xmlns="urn:oasis:names:tc:SAML:2.0:assertion">
<Issuer>anthem.cn.com</Issuer>
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
<SignedInfo>
<CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
<Reference URI="#_eeaaab87-0fcc-4ec1-93d3-ed623b27130c">
<Transforms>
<Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
<Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
</Transforms>
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<DigestValue>MkByT8QpjpBFszlr74Rx0IZNewk=</DigestValue>
</Reference>
</SignedInfo>
<SignatureValue>AYhBtCEl4CrsgsuWMaLEDP...</SignatureValue>
<KeyInfo>
<X509Data>
<X509Certificate>MII...</X509Certificate>
</X509Data>
</KeyInfo>
</Signature>
<Subject>
<NameID>VALERA</NameID>
<SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
<SubjectConfirmationData InResponseTo="_728ac076-7b14-4ce2-8efb-ed5c8c9b85f3" NotBefore="2019-03-27T12:32:34.839Z" NotOnOrAfter="2019-03-27T13:37:34.847Z"/>
</SubjectConfirmation>
</Subject>
<Conditions>
<AudienceRestriction>
<Audience>https://beta3dev.test.com/</Audience>
</AudienceRestriction>
</Conditions>
<AuthnStatement AuthnInstant="2019-03-27T12:37:41.843Z" SessionIndex="_56b775bf-32a7-4f35-a370-d707a653a5aa">
<AuthnContext>
<AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:Password</AuthnContextClassRef>
</AuthnContext>
</AuthnStatement>
<AttributeStatement>
<Attribute Name="FirstName">
<AttributeValue>valera</AttributeValue>
</Attribute>
</AttributeStatement>
</Assertion>
</samlp:Response>
It seems to be valid, we checked by online validators, but ADFS throws exception:
Microsoft.IdentityServer.Web.UnsupportedSamlResponseException: MSIS7029: The SAML response has content that is not supported.
So, The question is: What's wrong with saml?
P.S. Actually, we don't know how an idp intiated scenario works. Maybe there is some minimum pack of claims or we can't login because we don't have working stubs. It will be nice to get some more info about this dataflow.
Ok, it's working now.
There is no request in IdP initiated scenario, so we removed all InResponseTo attributes.
AuthnContext changed to PasswordProtectedTransport.
Name Id can be included but there should be no NotBefore attribute.
So I am trying to test a SOAP endpoint with SoapUI.
This is how my SOAP request looks like
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ns="http://docs.oasis-open.org/ws-sx/ws-trust/200512" xmlns:u="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
<soapenv:Header>
<o:Security soapenv:mustUnderstand="1" xmlns:o="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
<o:UsernameToken u:Id="uuid-6a13a244-dac6-42c1-84c5-cbb345b0c4c4-1">
<o:Username>username</o:Username>
<o:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">password</o:Password>
</o:UsernameToken>
</o:Security>
</soapenv:Header>
<soapenv:Body>
<ns:RequestSecurityToken Context="?">
<!--You may enter ANY elements at this point-->
</ns:RequestSecurityToken>
</soapenv:Body>
</soapenv:Envelope>
I keep getting this response
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<soap:Fault>
<faultcode>soap:MustUnderstand</faultcode>
<faultstring>MustUnderstand headers: [{http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd}Security] are not understood.</faultstring>
</soap:Fault>
</soap:Body>
</soap:Envelope>
If I change the value of mustUnderstand to 0, it gives this error
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<soap:Fault>
<faultcode>soap:Server</faultcode>
<faultstring>These policy alternatives can not be satisfied:
{http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/}SupportingTokens
{http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/}UsernameToken</faultstring>
</soap:Fault>
</soap:Body>
</soap:Envelope>
My security policy looks like below:
<wsp:Policy xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
wsu:Id="UserNameWSTrustBinding_IWSTrust13Async_policy">
<wsp:ExactlyOne>
<wsp:All>
<sp:SupportingTokens xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/">
<wsp:Policy>
<sp:UsernameToken
sp:IncludeToken="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/AlwaysToRecipient">
<wsp:Policy></wsp:Policy>
</sp:UsernameToken>
</wsp:Policy>
</sp:SupportingTokens>
</wsp:All>
</wsp:ExactlyOne>
</wsp:Policy>
Not sure what I am missing now. Does anyone know what I am missing?
I figured out the answer. We were not using org.apache.cxf:cxf-rt-ws-security and org.apache.cxf:cxf-rt-ws-policy jars. I will write a post to explain this in detail.
I'm trying to configure SimpleSAMLphp with a FederationMetadata.xml file generated by an AD FS 2.0 server (some of which you can see below - I have replaced the middle portion of the domain with the word "domain").
Since our web application is not on their network, it can't see the machines on the .local domain. I don't know much about ADFS and SAML but I thought that the IdP endpoints had to be accessible by the SP. However the technical contact for the IdP keeps saying that all we need is this file and that it doesn't matter that the SP is external to the network.
Is there something I'm missing here? Can the IdP and the SP communicate using this metadata?
<EntityDescriptor ID="**ID**" entityID="http://adfs2.domain.local/adfs/services/trust" xmlns="urn:oasis:names:tc:SAML:2.0:metadata">
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:SignedInfo>
<ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
<ds:Reference URI="**URI**">
<ds:Transforms>
<ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
</ds:Transforms>
<ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
<ds:DigestValue>**digest**</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>**signature**</ds:SignatureValue>
<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
<X509Data>
<X509Certificate>**cert**</X509Certificate>
</X509Data>
</KeyInfo>
</ds:Signature>
<RoleDescriptor xsi:type="fed:ApplicationServiceType" protocolSupportEnumeration="http://docs.oasis-open.org/ws-sx/ws-trust/200512 http://schemas.xmlsoap.org/ws/2005/02/trust http://docs.oasis-open.org/wsfed/federation/200706" ServiceDisplayName="adfs2.domain.local" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:fed="http://docs.oasis-open.org/wsfed/federation/200706">
<KeyDescriptor use="encryption">
<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
<X509Data>
<X509Certificate>**cert**</X509Certificate>
</X509Data>
</KeyInfo>
</KeyDescriptor>
<fed:ClaimTypesRequested>
<auth:ClaimType Uri="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress" Optional="true" xmlns:auth="http://docs.oasis-open.org/wsfed/authorization/200706">
<auth:DisplayName>E-Mail Address</auth:DisplayName>
<auth:Description>The e-mail address of the user</auth:Description>
</auth:ClaimType>
<auth:ClaimType Uri="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname" Optional="true" xmlns:auth="http://docs.oasis-open.org/wsfed/authorization/200706">
<auth:DisplayName>Given Name</auth:DisplayName>
<auth:Description>The given name of the user</auth:Description>
</auth:ClaimType>
...
</fed:ClaimTypesRequested>
<fed:TargetScopes>
<EndpointReference xmlns="http://www.w3.org/2005/08/addressing">
<Address>https://adfs2.domain.local/adfs/services/trust/2005/issuedtokenmixedasymmetricbasic256</Address>
</EndpointReference>
<EndpointReference xmlns="http://www.w3.org/2005/08/addressing">
<Address>https://adfs2.domain.local/adfs/services/trust/2005/issuedtokenmixedsymmetricbasic256</Address>
</EndpointReference>
<EndpointReference xmlns="http://www.w3.org/2005/08/addressing">
<Address>https://adfs2.domain.local/adfs/services/trust/13/issuedtokenmixedasymmetricbasic256</Address>
</EndpointReference>
<EndpointReference xmlns="http://www.w3.org/2005/08/addressing">
<Address>https://adfs2.domain.local/adfs/services/trust/13/issuedtokenmixedsymmetricbasic256</Address>
</EndpointReference>
<EndpointReference xmlns="http://www.w3.org/2005/08/addressing">
<Address>https://adfs2.domain.local/adfs/ls/</Address>
</EndpointReference>
<EndpointReference xmlns="http://www.w3.org/2005/08/addressing">
<Address>http://adfs2.domain.local/adfs/services/trust</Address>
</EndpointReference>
</fed:TargetScopes>
<fed:ApplicationServiceEndpoint>
<EndpointReference xmlns="http://www.w3.org/2005/08/addressing">
<Address>https://adfs2.domain.local/adfs/services/trust/2005/issuedtokenmixedasymmetricbasic256</Address>
</EndpointReference>
</fed:ApplicationServiceEndpoint>
<fed:PassiveRequestorEndpoint>
<EndpointReference xmlns="http://www.w3.org/2005/08/addressing">
<Address>https://adfs2.domain.local/adfs/ls/</Address>
</EndpointReference>
</fed:PassiveRequestorEndpoint>
</RoleDescriptor>
</EntityDescriptor>
Your SP and their IdP do not need to communicate at all. Once you have exchanged metadata, trust is established between your SP and their IdP. SAML has no requirements on how the metadata is exchanged. Some people do it through email, some published it to a webserver, others generate it dynamically on their IdP or SP and some will just provide you with the data values (cert, endpoints, etc) and have you construct the metadata yourself.
What is important is that the user logging in has access to both the SP and IdP. The most common SAML profile is the SP redirecting the user's browser to the IdP and then after login, the IdP causes the browser to POST back to the SP.
There are other profiles to SAML, that are not frequently used, the require SP to IdP communication. In your case the IdP doesn't support that profile.
I have to do RequestSecurityToken request with certificate signature and timestamp with SoapUI to get security token to use it in other requests, but I have problem to implement it correctly.
Here are correct request, with different application, but with same certificate:
<o:Security s:mustUnderstand="1" xmlns:o="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
<u:Timestamp u:Id="_0">
<u:Created>2016-10-24T14:35:54.851Z</u:Created>
<u:Expires>2016-10-24T14:40:54.851Z</u:Expires>
</u:Timestamp>
<o:BinarySecurityToken u:Id="uuid-e5fff67c-e3ce-4c63-86da-9661adfd6e0c-2" ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3" EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary">...MIIFgTCCBGmgAwIBAgIKOePZb(shortened)...</o:BinarySecurityToken>
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
<SignedInfo>
<CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
<Reference URI="#_0">
<Transforms>
<Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
</Transforms>
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<DigestValue>tsLKDNU0lJ5SB1p75WGVjd7LMHc=</DigestValue>
</Reference>
<Reference URI="#_1">
<Transforms>
<Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
</Transforms>
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<DigestValue>4QwJS9rCbZb1B3DcR37qnuJgSl4=</DigestValue>
</Reference>
</SignedInfo>
<SignatureValue>...gmAXzaf8hhj44/M0Q(shortened)...</SignatureValue>
<KeyInfo>
<o:SecurityTokenReference>
<o:Reference URI="#uuid-e5fff67c-e3ce-4c63-86da-9661adfd6e0c-2"/>
</o:SecurityTokenReference>
</KeyInfo>
</Signature>
</o:Security>
In SoapUI, in WSS config I add as keystore my certificate and made outgoing configuration, where are make timestmap and signature. In Signature, I configure it as binary security token, choose my keystore, alias and password. I have experimented with methods, but most closer result to correct one was this:
<wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
<u:Timestamp u:Id="TS-6EB3E416E924850AA51477473502423447">
<u:Created>2016-10-26T09:18:22.423Z</u:Created>
<u:Expires>2016-10-26T09:23:22.423Z</u:Expires>
</u:Timestamp>
<wsse:BinarySecurityToken EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary" ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3" u:Id="X509-6EB3E416E924850AA51477473502407442">...CCBGmgAwIBAgIKOeP(shortened)..." xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:SignedInfo>
<ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
<ds:Reference URI="#id-6EB3E416E924850AA51477473502408445">
<ds:Transforms>
<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
</ds:Transforms>
<ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<ds:DigestValue>ylZ7mgRanKsz3pYpbSXtE3FoVcc=</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>...PwHLpHxINEYUGoCM+Tsz9ucg(shortened)...</ds:SignatureValue>
<ds:KeyInfo Id="KI-6EB3E416E924850AA51477473502407443">
<wsse:SecurityTokenReference u:Id="STR-6EB3E416E924850AA51477473502407444">
<wsse:Reference URI="#X509-6EB3E416E924850AA51477473502407442" ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3"/>
</wsse:SecurityTokenReference>
</ds:KeyInfo>
</ds:Signature>
</wsse:Security>
On this request, i have response with error message
An error occurred when verifying security for the message.
One of differences what I see, is that in correct request there are two references with different URI, than in SoapUI request, but I can't figure out, how to simulate correct request in SoapUI. I would be glad to get some recommendation, maybe someone had the similar problem.
from default soapui only signs the soap-body element.
but you can add each other element from the "Parts:" configuration.
add the following (ID, Name, Namespace, Encode) in the Parts table:
First entry to sign timestamp content
leave ID empty
Timestamp
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
Element
Second entry to sign body content
leave ID empty
Body
http://schemas.xmlsoap.org/soap/envelope/
Element
and soapui will sign the timestamp and body element.
remark: the Timestamp needs to be added before the "Signature" in the list of WSS-Entries.
we have a webservice which uses soap security header like below.
I'm posting the header part alone which i want to get/capture/dump the entire soap header infos using spring inteceptors.
<soapenv:Envelope xmlns:per="http://com/myinfo/webservices/personservice" xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Header>
<wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
<wsse:BinarySecurityToken EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary" ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3" wsu:Id="X509-C65BABCE48EB203BE51445418168726378">MIIDQzCCAiugAwIBAgIEazX3vTANBgkqhkiG9w0BAQsFADBSMQswCQYDVQQGEwJTRzELMAkGA1UECBMCU0cxCzAJBgNVBAcTAlNHMQwwCgYDVQQKEwNBQ04xDDAKBgNVBAsTA0FDTjENMAsGA1UEAxMEbWl3czAeFw0xNTEwMTQwMzAxMTNaFw0xNjAxMTIwMzAxMTNaMFIxCzAJBgNVBAYTAlNHMQswCQYDVQQIEwJTRzELMAkGA1UEBxMCU0cxDDAKBgNVBAoTA0FDTjEMMAoGA1UECxMDQUNOMQ0wCwYDVQQDEwRtaXdzMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAmYtbz0BhRpHmhBWZO2I7tSY2Od5uvM0qRoJqyjr/I9fl6XOwXINIa+tBoVGeojJ18tZ7hRe24uPR45cQPBsOG73ClWPkhMV9jhcXkStvtBTnVYsJ7uUgciD5o64RQHEKQQ4imClBiV0n/3zCj3/BTv+LGhTdisMEbMZfoNk45nw5Kpv98yt/u9PtC/OclsOaeDM0rhWcVRQRnbAKcOwUcNK/MSsl+Cs2SFr6LQPByXAkPTZvOQMLO8cCWST8jt+wGOFVP3ZtU+PA2jNEkskQuWk03Ee74wVL0sHTwhDuuyWwUZTUR//fZRBSIgHGWIpEISkCg5u4VarPP/D34UOu4wIDAQABoyEwHzAdBgNVHQ4EFgQUc4EjVIcn7U5lDKSO6a4a9YptdF4wDQYJKoZIhvcNAQELBQADggEBACxSa36jLxaE5wC62trVAM1JId2pEUCjhPErgsFZpVA40q5lzo5rhr3wSIq2W7MYE2U7PvuAexsUatpBIHLnCZ4MzgA+drlYtVM2ghYmU8Qq8bv1uBAVZTDb2ni3T3mytjelAE4tbU2xhz9RZ2fSBkuzPguqX4GyuJfhtCmC1A25Xszek8JIzfzTP+dZvqfFvipv2IUE3yqYsbVEynZcaLVLNPvqTwrhUn4JQ7CcuDPGzjzCfMckM2aeobqo7WaA5KcHo8SMCwCmnLqjKBBzIx3c5H7U0TOTLXklwxizi580+T8VVzwELr6TWD6B0zICyhyw+cHDQKKg0Rswb1ygshU=</wsse:BinarySecurityToken>
<ds:Signature Id="SIG-C65BABCE48EB203BE51445418168727381" xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:SignedInfo>
<ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
<ec:InclusiveNamespaces PrefixList="aud per soapenv" xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#"/>
</ds:CanonicalizationMethod>
<ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
<ds:Reference URI="#id-C65BABCE48EB203BE514452344634628">
<ds:Transforms>
<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
<ec:InclusiveNamespaces PrefixList="aud per" xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#"/>
</ds:Transform>
</ds:Transforms>
<ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<ds:DigestValue>EdM5VqPByiliQndKko9KuNv1B2I=</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>b1JskNxbAat6oc4UfPOoNYEcVcYe2a7PKfPn/Ttn+unzzmywn/gwlqJwo38Rq4iWUdAPtUqeXEnp/F6U39V/tqg3OYUx6/FRT1yrqpyuLfuJGW9MW6laFZ2UCfJvFEe4QEUU4OdjXrTVmGy9PqFPCd8QBCmpbQfCyvr0nvuvFO0G5Rd0NAP45Bb276ieow7lGXMXIYkRmX956pmMdzrtzw9kneIcCaSqLZ9xBGExMuLErs0s6MAlCkYu3m84h4J7UlTpHtz2+LUZM0eOnPqU63xYVblnxwDs//nN8Tn4hC6gz1oGr4SC5wU8GjZjYBpTqy7nBfx7qMBQjjHDEX2D2A==</ds:SignatureValue>
<ds:KeyInfo Id="KI-C65BABCE48EB203BE51445418168726379">
<wsse:SecurityTokenReference wsu:Id="STR-C65BABCE48EB203BE51445418168726380">
<wsse:Reference URI="#X509-C65BABCE48EB203BE51445418168726378" ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3"/>
</wsse:SecurityTokenReference>
</ds:KeyInfo>
</ds:Signature>
</wsse:Security>
</soapenv:Header>
</soapenv:Envelope>
Wanted to capture all elements between
<soapenv:Header> </soapenv:Header>
How do i achieve using spring endpoint inteceptors
Any help will be much appreciated.
Thanks
In your interceptor, you can use the following expression to get the entire <soapenv:Header> element:
((SoapMessage)messageContext.getRequest()).getSoapHeader().getSource()
Typically, you would then pass the Source object to a Transformer to transform it into the desired form, e.g. to serialize it and write it to a log file.