I've a problem to get a token from the STS. I get the token if I use SoapUI. But I don't know how to configure my client application that it creates a request like:
<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:a="http://www.w3.org/2005/08/addressing">
<s:Header>
<a:Action s:mustUnderstand="1">http://docs.oasis-open.org/ws-sx/ws-trust/200512/RST/Issue</a:Action>
<a:To s:mustUnderstand="1">https://.../idp/sts.wst</a:To>
<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>
<o:Username>xxxUSERxxx</o:Username>
<o:Password>xxxPWxxx</o:Password>
</o:UsernameToken>
</o:Security>
</s:Header>
<s:Body>
<trust:RequestSecurityToken Context="http://client.ws.com" xmlns:trust="http://docs.oasis-open.org/ws-sx/ws-trust/200512">
<wsp:AppliesTo xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy">
<a:EndpointReference>
<a:Address>xxxADDRESSxxx</a:Address>
</a:EndpointReference>
</wsp:AppliesTo>
<trust:KeyType>http://docs.oasis-open.org/ws-sx/ws-trust/200512/Bearer</trust:KeyType>
<trust:RequestType>http://docs.oasis-open.org/ws-sx/ws-trust/200512/Issue</trust:RequestType>
<trust:TokenType>http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV2.0</trust:TokenType>
</trust:RequestSecurityToken>
</s:Body>
</s:Envelope>
Can anybody help me?
Does the STS expose a metadata exchange endpoint? If so you could create a client proxy via visual studio's "add service reference" dialogue (or just use svcutil).
You could use this article as a starting point.
Related
I am writing a SoapCore web service in .NET Core 5.0 and I have successfully been able to execute the request via SOAPUI and get back a valid response. The only thing I don't like is that it puts unwanted prefixes in the repose message. for example in this response:
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<s:Body>
<getMeterIntervalDataByTimeSliceResponse xmlns="http://tempuri.org/">
<getMeterIntervalDataByTimeSliceResult xmlns:d4p1="http://schemas.datacontract.org/2004/07/MeterDataWebService.Models" xmlns:i="http://www.w3.org/2001/XMLSchema-instance">
<d4p1:AccountId>1234567890</d4p1:AccountId>
<d4p1:ID>0</d4p1:ID>
<d4p1:IntervalEndTime>2020-12-22T15:30:57.3705724-05:00</d4p1:IntervalEndTime>
<d4p1:IntervalLengthInSeconds>PT5M</d4p1:IntervalLengthInSeconds>
<d4p1:Load>2345.8010350836185</d4p1:Load>
<d4p1:MeterChannel>1</d4p1:MeterChannel>
<d4p1:TimeZone>UT</d4p1:TimeZone>
<d4p1:UnitOfMeasure>KM</d4p1:UnitOfMeasure>
<d4p1:UtcOffset>0</d4p1:UtcOffset>
</getMeterIntervalDataByTimeSliceResult>
</getMeterIntervalDataByTimeSliceResponse>
</s:Body>
</s:Envelope>
How do I get rid of the "d4p1" prefix?
I figured it out. It was in my Startup.cs class.
app.UseSoapEndpoint("/Service.asmx", new
BasicHttpBindingg(), SoapSerializer.XmlSerializer);
I forgot to add the SoapSerializer.XmlSerializer part
I have a .NET application that is consuming a Java WCF, and I need to change my Reference.cs to set the ServiceVersion, I don't know how I can do this.
Someone has some idea?
My SOAP XML should be:
<s:Header>
<ns:TocHeader>
<ns:Message>
<ns:X>
<ns1:ServiceVersion>12.05</ns1:ServiceVersion>
</ns:X>
</ns:Message>
</ns:TocHeader>
</s:Header>
The XML that .NET is generating:
<s:Header>
<ns:TocHeader xsi:nil="true"/>
</s:Header>
I've been trying to call a third-party webservice from a .NET client. I have had to set some custom headers for each request in order to adhere to their Authentication requirements.
I have used this answer in order for me to get the request header values to appear as so:
<?xml version="1.0" encoding="UTF-8"?>
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
<s:Header>
<wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" s:mustUnderstand="0">
<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>Jimbob</wsse:Username>
<wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">P#ssword</wsse:Password>
</wsse:UsernameToken>
</wsse:Security>
</s:Header>
<s:Body>
...
</s:Body>
</s:Envelope>
(I am doing this by setting the a custom <endpoint><headers /></endpoint> section in config)
I have inspected the request via Fiddler and it is sending the correct header values, and the webservice is returning expected results.
However, the client is throwing the following exception when it receives the result:
System.ServiceModel.ProtocolException : The header 'Security' from the namespace 'http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd' was not understood by the recipient of this message, causing the message to not be processed. This error typically indicates that the sender of this message has enabled a communication protocol that the receiver cannot process. Please ensure that the configuration of the client's binding is consistent with the service's binding.
The relevant part of the repsonse (from Fiddler) is this:
<?xml version="1.0" encoding="UTF-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap: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" soap:mustUnderstand="1">
<wsse:UsernameToken wsu:Id="UsernameToken-371676">
<wsse:Username>SOMEUSERTOKEN</wsse:Username>
<wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">SOMEUSERTOKEN</wsse:Password>
</wsse:UsernameToken>
</wsse:Security>
</soap:Header>
<soap:Body>
...
<soap:Body>
</soap:Envelope>
Basically I'm now lost. I presume I need to perform some sort of message inspection to flag that header as understood, but it does seem quite a lot of heavy lifting just to interpret a result (which I'm already getting from the webservice).
Any help is much appreciated.
If you just want to do the authentication , I did used the following code for my c# console application and it worked. I used this code in the config file though under <system.serviceModel>-><client>-> <endpoint>
<headers>
<wsse:Security mustUnderstand="1" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" >
<wsse:UsernameToken xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
<wsse:Username>SOMEUSERTOKEN</wsse:Username>
<wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">SOMEUSERTOKEN</wsse:Password>
</wsse:UsernameToken>
</wsse:Security>
</headers>
What I'm trying to achieve is to format following response message:
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" xmlns:a="http://schemas.xmlsoap.org/ws/2004/08/addressing">
<s:Header>
<a:Action s:mustUnderstand="1">http://schemas.xmlsoap.org/ws/2004/08/addressing/fault</a:Action>
<a:To s:mustUnderstand="1">http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous</a:To>
</s:Header>
<s:Body>
<s:Fault>
<faultcode xmlns:a="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">a:FailedAuthentication</faultcode>
<faultstring xml:lang="de-DE">Mindestens ein Sicherheitstoken in der Nachricht konnte nicht validiert werden.</faultstring>
<detail>
<myCustonDetail>
...
</myCustonDetail>
</detail>
</s:Fault>
</s:Body>
</s:Envelope>
I know that I can use FaultContract and IErrorHandler to achieve this, however this handles only scenario when exception is thrown within service method itself. But the exception are also raised before service method get called (during checking Message Security etc.) Then by default the message without detail part is returned.
Unfortunately to fulfil some standard requirements I need to append detailed information for every Fault response. Is it possible in .NET? (without writing own implementation of WS-* security standards which I have to use)
I have run into an exasperating problem getting a Java service client to communicate successfully with a WCF service. I have overcome many hurdles, and I believe that this is my last one. The problem boils down to how Java Axis + WSS4J seem to handle xml namespaces. The Java platform seem to be very rigid in what they expect for xml namespace prefixes, and as such, do not understand the WCF reply messages.
My problem in a nutshell is as follows. I have an xml response similar to the following from my WCF service:
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" xmlns:a="http://www.w3.org/2005/08/addressing" xmlns:u="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
<s:Header>
<a:Action s:mustUnderstand="1" u:Id="_3">http://tempuri.org/IProcessor/DoProcessingResponse</a:Action>
<h:CorrelationID xmlns:h="http://tempuri.org/">1234</h:CorrelationID>
<a:RelatesTo u:Id="_4">uuid:40f800a0-9613-4f4a-96c5-b9fd98085deb</a:RelatesTo>
<o:Security s:mustUnderstand="1" xmlns:o="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
<!-- WS-Security header stuff -->
</o:Security>
</s:Header>
<s:Body u:Id="_1">
<e:EncryptedData Id="_2" Type="http://www.w3.org/2001/04/xmlenc#Content" xmlns:e="http://www.w3.org/2001/04/xmlenc#">
<e:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>
<e:CipherData>
<e:CipherValue>NfA6XunmyLlT2ucA+5QneoawHm+imcaCltDAJC1mRZOSxoB6YGpDLY1FyVykPbPGDoFGUESLsmvvbD62sNnRrgE+AuKPo+1CD3DF4LfurRcEv9A50ba9V+ViqlrhydhK</e:CipherValue>
</e:CipherData>
</e:EncryptedData>
</s:Body>
</s:Envelope>
This response uses simple one-character namespace prefixes for most things, such as 's' for SOAP Envelope, 'a' for WS-Addressing, 'o' for 'WS-Security', etc. The Java client, namely WSS4J, seems to expect the following:
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:wsa="http://www.w3.org/2005/08/addressing" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
<soap:Header>
<wsa:Action soap:mustUnderstand="1" wsu:Id="_3">http://tempuri.org/IProcessor/DoProcessingResponse</wsa:Action>
<h:CorrelationID xmlns:h="http://tempuri.org/">1234</h:CorrelationID>
<wsa:RelatesTo wsu:Id="_4">uuid:40f800a0-9613-4f4a-96c5-b9fd98085deb</a:RelatesTo>
<wsse:Security soap:mustUnderstand="1" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
<!-- WS-Security header stuff -->
</wsse:Security>
</soap:Header>
<soap:Body u:Id="_1">
<xenc:EncryptedData Id="_2" Type="http://www.w3.org/2001/04/xmlenc#Content" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
<xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>
<xenc:CipherData>
<xenc:CipherValue>NfA6XunmyLlT2ucA+5QneoawHm+imcaCltDAJC1mRZOSxoB6YGpDLY1FyVykPbPGDoFGUESLsmvvbD62sNnRrgE+AuKPo+1CD3DF4LfurRcEv9A50ba9V+ViqlrhydhK</xenc:CipherValue>
</xenc:CipherData>
</xenc:EncryptedData>
</soap:Body>
</soap:Envelope>
Upon receipt of my response message, the Java client and WSS4J seem to want to look up elements by their own internal xml aliases, such as 'wsa' for WS-Addressing, and 'wsse' for WS-Security Extensions. Since neither of those namespaces are present in the actual response xml, exceptions are thrown.
I am wondering if there is any simple way to transform an xml document from one set of namespaces to another set using C#, .NET, and the System.Xml namespace. I've poked around with XmlNamespaceManager a bit, but it does not seem to fully support what I need...or at least, I have been unable to find any really useful examples, and am not fully sure how it works. I am trying to avoid having to write some heavy-duty process to handle this manually myself, as I do not want to drastically impact the performance of our services when called by a Java Axis/WSS4J client.
This particular problem seemed to stem from an old and buggy version of WSS4J. Newer versions do not seem to have this problem, and it is no longer an issue.