I need your valuable help/support in solving the below issue Im facing.
I have a requirement to develop a service in Oracle SOA BPEL 11g(11.1.1.5) to invoke a SAML Assertion secured Webservice(ServiceB).
The SAML Assertion will be the response from another Webservice(ServiceA) which will be invoked prior to invoking ServiceB.
This SAML assertion which came as response from the ServiceA should be passed to enter code hereServiceB at the headers.
Below are the ways I tried but failed
1) created a header variable and assigned the SAML assertion to it and added it as a Header property while Invoking the ServiceB.
Error Message:‘The token is missing or is of the wrong data type.’
2) Added OWSM policy 'oracle/wss10_saml_token_client_policy' in the composite at Adapter binding level. And tried passing the Value of SAML by defining a variable at the binding level.
Error Message: 'Unable to access the following endpoint(s): https://www.tpvs.hmrc.gov.uk/dps/dps.jws'
I tried testing the SOAP serviceB from SOAPUI passing the SAML details in headers and its successful.
Request the community to please throw some light and help me in this regards.
Please let me know if you need any further information from my end.
TIA
Shan
Below is the Sample request with SAML assertion at the header:
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<SOAP-ENV:Header>
<wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
<saml:Assertion xmlns="urn:oasis:names:tc:SAML:1.0:assertion" xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion" xmlns:samlp="urn:oasis:names:tc:SAML:1.0:protocol" AssertionID="cc36a795db335637b5b0da5c383e5a77" IssueInstant="2019-06-21T08:56:56.268Z" Issuer="http://online.hmrc.gov.uk/SAML" MajorVersion="1" MinorVersion="1"><saml:Conditions NotBefore="2019-06-21T09:56:56.268Z" NotOnOrAfter="2019-06-21T13:56:56.268Z"></saml:Conditions><saml:AuthenticationStatement AuthenticationInstant="2019-06-21T09:56:56.268Z" AuthenticationMethod="urn:oasis:names:tc:SAML:1.0:am:unspecified"><saml:Subject><saml:NameIdentifier Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified" NameQualifier="SubjectNameQualifier">SubjectName</saml:NameIdentifier><saml:SubjectConfirmation><saml:ConfirmationMethod>urn:oasis:names:tc:SAML:1.0:cm:sender-vouches</saml:ConfirmationMethod></saml:SubjectConfirmation></saml:Subject><saml:SubjectLocality IPAddress="32.42.18.148"></saml:SubjectLocality></saml:AuthenticationStatement><saml:AttributeStatement><saml:Subject><saml:NameIdentifier Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified" NameQualifier="SubjectNameQualifier">SubjectName</saml:NameIdentifier><saml:SubjectConfirmation><saml:ConfirmationMethod>urn:oasis:names:tc:SAML:1.0:cm:sender-vouches</saml:ConfirmationMethod></saml:SubjectConfirmation></saml:Subject><saml:Attribute AttributeName="SESSION_ID" AttributeNamespace="http://online.hmrc.gov.uk/SAML"><saml:AttributeValue>28c0d81f-3385-4c45-b91e-3b80c5713bd9</saml:AttributeValue></saml:Attribute><saml:Attribute AttributeName="USER_AUTHENTICATION_TOKEN" AttributeNamespace="http://online.hmrc.gov.uk/SAML"><saml:AttributeValue>os0EEQtZLq6kfzm+57M6wbfaWXRGXKV63uV4RPqbd+SKvSS3DeqJ3922dAPw0xL0GQGJgqcTmtkcgHEfuf2jLnywuy427nWe7E0D4KRnz9g77PdH58bDCOV2vAuVHL9p9HFeyO1Oniy7ct9o143rvJ+o6GZtLhotWKnZ9Yi+IW3IbskIWEVIf7OOyHRLq5p3YnLawZnM6LY51wBhpUQCMkornRpjejcrUKTWjlwesKg=</saml:AttributeValue></saml:Attribute></saml:AttributeStatement><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:CanonicalizationMethod><ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#hmac-sha1"></ds:SignatureMethod><ds:Reference URI="#cc36a795db335637b5b0da5c383e5a77"><ds:Transforms><ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"></ds:Transform><ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"><ec:InclusiveNamespaces xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#" PrefixList="code ds kind rw saml samlp typens #default"></ec:InclusiveNamespaces></ds:Transform></ds:Transforms><ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"></ds:DigestMethod><ds:DigestValue>8I/Ilid0fZIqHvXtCZESjgpw9h4=</ds:DigestValue></ds:Reference></ds:SignedInfo><ds:SignatureValue>hCNEvtoRKxNDFFtuXmpzCcd4R5o=</ds:SignatureValue></ds:Signature></saml:Assertion>
</wsse:Security>
</SOAP-ENV:Header>
<SOAP-ENV:Body>
<m:DPSretrieve xmlns:m="https://tpvs.hmrc.gov.uk/dps">
<m:version>1</m:version>
<m:vendorID>your 4 digit vendorID</m:vendorID>
<m:service>PAYE</m:service>
<m:entityType>EmpRef</m:entityType>
<m:entity>as advised by SDS Team</m:entity>
<m:dataType>P6</m:dataType>
<m:got>0</m:got>
<m:nItems>0</m:nItems>
</m:DPSretrieve>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
==============================================================
Related
Created an application with this soap call createApplication()
<soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsd="http://org.apache.axis2/xsd" xmlns:xsd1="http://model.common.application.identity.carbon.wso2.org/xsd">
<soapenv:Header/>
<soapenv:Body>
<xsd:createApplication>
<xsd:serviceProvider>
<xsd1:applicationName>travelocity.com</xsd1:applicationName>
<xsd1:description>SaMLApp</xsd1:description>
</xsd:serviceProvider>
</xsd:createApplication>
Added a service provider with this soap call addRPServiceProvider()
<soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsd="http://org.apache.axis2/xsd"
xmlns:xsd1="http://dto.saml.sso.identity.carbon.wso2.org/xsd">
<soapenv:Header/>
<soapenv:Body>
<xsd:addRPServiceProvider>
<xsd:spDto><xsd1:assertionConsumerUrl>http://localhost:8080/travelocity.com/home.jsp</xsd1:assertionConsumerUrl>
<xsd1:doSignAssertions>true</xsd1:doSignAssertions>
<xsd1:doSignResponse>true</xsd1:doSignResponse>
<xsd1:doSingleLogout>true</xsd1:doSingleLogout>
<xsd1:issuer>sophos.com</xsd1:issuer>
<xsd1:nameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</xsd1:nameIDFormat>
<xsd1:useFullyQualifiedUsername>true</xsd1:useFullyQualifiedUsername>
</xsd:spDto>
</xsd:addRPServiceProvider>
Now how should I link those by calling updateApplication()? What should be the attributes of update application soap call? I referred this, but could not figure out the linking part in updateApplication().
Note: I can create these on WSO2 IS management console web UI. I could not create them through API calls.
SAML application will be added as an inbound authentication configuration of the Service Provider. So when you call updateApplication method, use the issuer name that you used to create the SAML application (travelocity.com in your case) as the inboundAuthKey in inboundAuthenticationConfig section. If you need a code sample please follow this.
I am using ADFS 3.0 and SAML 2. I got errors like:
Exception:
'Element' is an invalid XmlNodeType. StackTrace: at
System.Xml.XmlReader.ReadEndElement() at Microsoft.IdentityServer.Protocols.Saml.SamlProtocolSerial1)izer.ReadAuthnRequest(XmlReader
reader)
Passive pipeline error
The saml request was:
<samlp:AuthnRequest xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" ID="DH7a49776ef7c040d09b2c661821bd5f76" AssertionConsumerServiceURL="https://auth-dev.ServiceProvider.com/clientOrg/SAML/Login" Destination="https://federation.example.net/adfs/ls/IdpInitiatedSignOn.aspx" IssueInstant="2017-04-20T14:49:35.6414575Z" Version="2.0" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
<saml:Issuer>https://auth.ServiceProvider.com/clientOrg</saml:Issuer>
<samlp:NameIDPolicy AllowCreate="true" />
<samlp:forceAuthn>true</samlp:forceAuthn>
</samlp:AuthnRequest>
If the error message is too vague, how to further narrow down and trouble shoot this issue raised from the AD FS side?
Thanks.
Make sure your request is spec compliant. Use a mature SAML2 library to generate the request instead of crafting it by hand.
What is https://auth.ServiceProvider.com/clientOrg using to generate these requests?
if you remove below string, your request becomes compliant.
<samlp:forceAuthn>true</samlp:forceAuthn>
See sample at https://msdn.microsoft.com/en-us/library/ee895365.aspx to see how to use forceauthn. I also fixed destination as ad fs endpoint is /adfs/ls not /adfs/ls/idpinitiatedsignon.aspx
<samlp:AuthnRequest xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" ForceAuthn="true" ID="DH7a49776ef7c040d09b2c661821bd5f76" AssertionConsumerServiceURL="https://auth-dev.ServiceProvider.com/clientOrg/SAML/Login" Destination="https://federation.example.net/adfs/ls/" IssueInstant="2017-04-20T14:49:35.6414575Z" Version="2.0" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
<saml:Issuer>https://auth.ServiceProvider.com/clientOrg</saml:Issuer>
<samlp:NameIDPolicy AllowCreate="true" />
</samlp:AuthnRequest>
Review spec at http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf for correct authnrequest.
Use validators like https://www.samltool.com/validate_xml.php to check if your request is compliant. Others might have more suggestions.
I referred to the below link to generate a SAML token from SOAP UI. But there is no service exposed in IS to validate a SAML token.
http://charithaka.blogspot.ae/2013/07/broker-trust-relationships-with-wso2.html
SAML Sample request in SOAP UI
RST Request
{Service.url}/services/wso2carbon-sts
{Service.url}/services/wso2carbon-sts.wso2carbon-stsHttpsSoap12Endpoint/
<soapenv:Envelope xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope">
<soapenv:Header xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing">
<wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" soapenv:mustUnderstand="true">
<wsu:Timestamp xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" wsu:Id="Timestamp-1">
<wsu:Created>2014-12-17T11:59:30.226Z</wsu:Created>
<wsu:Expires>2014-12-17T11:59:30.226Z</wsu:Expires>
</wsu:Timestamp>
<wsse:UsernameToken xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" wsu:Id="UsernameToken-2">
<wsse:Username>admin</wsse:Username>
<wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">admin</wsse:Password>
</wsse:UsernameToken>
</wsse:Security>
<wsa:To>https://localhost:9443/services/wso2carbon-sts</wsa:To>
<wsa:ReplyTo>
<wsa:Address>http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous</wsa:Address>
</wsa:ReplyTo>
<wsa:MessageID>urn:uuid:258de3bc-c053-4b41-93d5-5d292a896b3a</wsa:MessageID>
<wsa:Action>http://schemas.xmlsoap.org/ws/2005/02/trust/RST/Issue</wsa:Action>
</soapenv:Header>
<soapenv:Body>
<wst:RequestSecurityToken xmlns:wst="http://schemas.xmlsoap.org/ws/2005/02/trust">
<wst:RequestType>http://schemas.xmlsoap.org/ws/2005/02/trust/Issue</wst:RequestType>
<wst:TokenType>http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV2.0</wst:TokenType>
<wst:KeyType>http://schemas.xmlsoap.org/ws/2005/02/trust/Bearer</wst:KeyType>
<wst:Claims xmlns:wsp="http://schemas.xmlsoap.org/ws/2005/02/trust" wsp:Dialect="http://wso2.org/claims">
<wsid:ClaimType xmlns:wsid="http://schemas.xmlsoap.org/ws/2005/05/identity" Uri="http://wso2.org/claims/emailaddress"></wsid:ClaimType>
<wsid:ClaimType xmlns:wsid="http://schemas.xmlsoap.org/ws/2005/05/identity" Uri="http://wso2.org/claims/givenname"></wsid:ClaimType>
</wst:Claims>
</wst:RequestSecurityToken>
</soapenv:Body>
</soapenv:Envelope>
Also used sts client from
https://svn.wso2.org/repos/wso2/carbon/platform/branches/turing/products/is/5.0.0/modules/samples/sts/sts-client
Validate token which is given in WSO2 IS -> Tools -> Validate SAML Request, does not seem to work for the use case in hand, when providing the generated RSTR(Response for Security Token Request).
Is there any difference between the sts client and the link provided above?
Looking for a way to validate SAML token via SOAP service(SOAP UI)?
Sample Client provided with WSO2IS 5.0.0 will call to a service (echo) secured with sts. So it validate the sts token internal before access the service but there it does not provide a separate API to validate the token.
And in the WSO2 IS -> Tools -> Validate SAML Request
It only validate the SAML logout request and login requests not the SAML assertion only.
But in IS 5.1.0 (from next release onwards) wso2carbon-sts API will provide a validation service
I wish to write custom policy .How would i start .
I couldn't find any blogs about that .
My issue is my client has been fixed header request for authentication.So The Username-token authentication scenario is perfect for me .But client unable to send the Proper format request as per the Scenario needed .
Its sending username password in some other format
<soapenv:Header>
<pr:authentication soapenv:actor="http://schemas.xmlsoap.org/soap/actor/next" soapenv:mustUnderstand="0" xmlns:pr="http://webservices.im.com/ProxyService">
<pr:user>mwp</pr:user>
<pr:password>MWp003</pr:password>
</pr:authentication>
</soapenv:Header>
But its not working in wso2 ESB Username-token scenario.Expecting input Header is like this
<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" soapenv:mustUnderstand="1">
<wsu:Timestamp wsu:Id="TS-4">
<wsu:Created>2014-06-02T07:15:21Z</wsu:Created>
<wsu:Expires>2014-06-02T08:38:41Z</wsu:Expires>
</wsu:Timestamp>
<wsse:UsernameToken wsu:Id="UsernameToken-3">
<wsse:Username>admin</wsse:Username>
<wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">admin</wsse:Password>
<wsse:Nonce EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary">byWKVY4stEATvTqaoNMswQ==</wsse:Nonce>
<wsu:Created>2014-06-02T07:15:21.304Z</wsu:Created>
</wsse:UsernameToken>
</wsse: >
</soapenv:Header
So what is the solution for this how would achieve this.
Thanks in advance.
ESB uses WS-Security specification to secure Web services. Therefore, client need to send messages according to that specification. But in your case, It seems to be your client sending user/password in custom SOAP headers. Then these can not be validated by ESB. There can be two solutions.
You need to modify your client to compliant with WS-Security spec.
You can write some custom handler (axis2 handler) to read custom headers in your message and validate user/password against the user store.
Basically WS-Security messages are also validated by a axis2 handler called Apache Rampart.
I apologize in advance if this post feels too long. But 1) this is my first post ever and 2) I have really been over the river and through the woods trying to figure this out.
The Add Service Reference feature in Visual Studio 2012 produces a proxy that (apparently) generates invalid SOAP messages. I suspect it has to do with serialization or how the proxy types are decorated but I cannot seem to figure it out. Help is much appreciated.
Detail 1. My environment is Visual Studio 2012 and I have created a .NET 4.5 class library with a service reference to https://sandbox-api.bancbox.com/v1/BBXPort?wsdl. I'm attempting to call the getClient() function; which is defined here. (http://www.bancbox.com/api/view/45)
The code looks like this:
public void GetClient()
{
// create an instance of the service reference proxy class
var bbx=newBBXClient();
bbx.ChannelFactory.Endpoint.Behaviors.Remove<System.ServiceModel.Description.ClientCredentials>();
bbx.ChannelFactory.Endpoint.Behaviors.Add(new CustomCredentials());
bbx.ClientCredentials.UserName.UserName="MY_USERNAME";
bbx.ClientCredentials.UserName.Password="MY_PASSWORD";
var customerId=newid {
subscriberReferenceId="44XX33YY"
};
var request=newgetClientRequest {
subscriberId=MY_SUBSCRIBER_ID,
clientId=customerId
};
var response=bbx.getClient(request);
}
Detail 2. I have made many successful calls into the web service via SoapUI. The successful SoapUI-produced SOAP messages look like this
<soapenv:Envelope xmlns:sch="schema.bancbox.com" xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Header>
<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-11">
<wsse:Username>MY_USERNAME</wsse:Username>
<wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">MY_PASSWORD</wsse:Password>
<wsse:Nonce EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary">tRLo6AlRKl+/rULiKq6A6g==</wsse:Nonce>
<wsu:Created>2013-02-22T18:32:02.204Z</wsu:Created>
</wsse:UsernameToken>
</wsse:Security>
</soapenv:Header>
<soapenv:Body>
<sch:getClient>
<getClientRequest>
<subscriberId>MY_SUBSCRIBER_ID</subscriberId>
<clientId>
<!--Optional:-->
<subscriberReferenceId>44XX33YY</subscriberReferenceId>
</clientId>
</getClientRequest>
</sch:getClient>
</soapenv:Body>
</soapenv:Envelope>
Detail 3. Per Fiddler, my failed SOAP messages look like this
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" xmlns:u="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
<s:Header>
<VsDebuggerCausalityData xmlns="http://schemas.microsoft.com/vstudio/diagnostics/servicemodelsink">uIDPozcAgEH0QhJHloqMBWUf3mAAAAAA5wy3enJkDUGU8IaMUCFyEjzfL+1Uez1HhAvEeFpJ+30ACQAA</VsDebuggerCausalityData>
<o:Security s:mustUnderstand="1" xmlns:o="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
<o:UsernameToken u:Id="uuid-6e1c9f81-0651-41f7-b659-26b191bf7e13-1" xmlns:u="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
<o:Username>MY_USERNAME</o:Username>
<o:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">MY_PASSWORD</o:Password>
<o:Nonce EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary">hGggJkxurSkHQ3MKoeBK6AmEHNs=</o:Nonce>
<u:Created>2013-02-23T11:24:47.663Z</u:Created>
</o:UsernameToken>
</o:Security>
</s:Header>
<s:Body xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<getClient xmlns="schema.bancbox.com">
<getClientRequest xmlns="">
<subscriberId>MY_SUBSCRIBER_ID</subscriberId>
<clientId>
<subscriberReferenceId>XX55YY22</subscriberReferenceId>
</clientId>
</getClientRequest>
</getClient>
</s:Body>
</s:Envelope>
The SOAP message above is produced when running the GetClient() method. GetClient throws the following Exception.
System.ServiceModel.FaultException
Unmarshalling Error: cvc-elt.4.2: Cannot resolve 'getClientRequest' to a type definition for element 'getClientRequest'.
When I replay the same failing message using SoapUI, I get the following response:
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<soap:Fault>
<faultcode>soap:Client</faultcode>
<faultstring>Unmarshalling Error: cvc-elt.4.2: Cannot resolve 'getClientRequest' to a type definition for element 'getClientRequest'. </faultstring>
</soap:Fault>
</soap:Body>
</soap:Envelope>
Detail 4. Based on my research, this indicates that the server on the other end is Apache CXS. It's choking on my SOAP request. So I started playing around with my SOAP message and submitting it via SoapUI.
The first glaring distance in the successful message and my fail message are these lines
SUCCESS
<sch:getClient>
<getClientRequest>
FAIL
<getClient xmlns="schema.bancbox.com">
<getClientRequest xmlns="">
So the first thing that I did was make my getClientRequest tag identical to the successful one.
<getClient xmlns="schema.bancbox.com">
<getClientRequest>
This produced the following response.
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<soap:Fault>
<faultcode>soap:Server</faultcode>
<faultstring>Found element {schema.bancbox.com}getClientRequest but could not find matching RPC/Literal part</faultstring>
</soap:Fault>
</soap:Body>
</soap:Envelope>
The next thing that I did is change the way the getClient tag is assigned a schema.
BEFORE
<getClient xmlns="schema.bancbox.com">
AFTER
<s:Envelope xmlns:bb="schema.bancbox.com" xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" xmlns:u="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
. . .
<bb:getClient>
<getClientRequest>
. . .
</bb:getClient>
The resultant SOAP message looks like this and it is successful.
<s:Envelope xmlns:bb="schema.bancbox.com" xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" xmlns:u="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
<s:Header>
<VsDebuggerCausalityData xmlns="http://schemas.microsoft.com/vstudio/diagnostics/servicemodelsink">uIDPozcAgEH0QhJHloqMBWUf3mAAAAAA5wy3enJkDUGU8IaMUCFyEjzfL+1Uez1HhAvEeFpJ+30ACQAA</VsDebuggerCausalityData>
<o:Security s:mustUnderstand="1" xmlns:o="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
<o:UsernameToken u:Id="uuid-6e1c9f81-0651-41f7-b659-26b191bf7e13-1" xmlns:u="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
<o:Username>MY_USERNAME</o:Username>
<o:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">MY_PASSWORD</o:Password>
<o:Nonce EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary">hGggJkxurSkHQ3MKoeBK6AmEHNs=</o:Nonce>
<u:Created>2013-02-23T11:24:47.663Z</u:Created>
</o:UsernameToken>
</o:Security>
</s:Header>
<s:Body xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<bb:getClient>
<getClientRequest>
<subscriberId>MY_SUBSCRIBER_ID</subscriberId>
<clientId>
<subscriberReferenceId>XX55YY22</subscriberReferenceId>
</clientId>
</getClientRequest>
</bb:getClient>
</s:Body>
</s:Envelope>
So the million dollar questions are WHY and HOW.
*WHY does the .NET proxy class serialize the SOAP message the way it does?
*HOW do I fix it? How can I may my proxy serialize into the SOAP message above? How can I force the serializer to define shorthand for the message namespace in the Envelop and then use the shorthand in the message tag?
FYI, to even get to this point I had to get past a number of WCF WSE issues and ended up implementing the solution so generously provided on Rich Stahls blog. I would post the link but apparently I don't have enough rep.
From I understand, the SOAP message that WCF produces is syntactically correct. However, Java CXF web services are very rigid with regards to the SOAP messages that they will accept.
The solution to specific problem setting aliases for xml namespace definitions in the Operation node of the SOAP messages produced by WCF proxies involves implementing a Custom Message Inspector is detailed here: Force WCF to create an xml namespace alias in client proxy.
This has completely resolved my issue.