| Author |
Message
|
| salvador.wbi |
 Posted: Wed Jun 18, 2014 2:32 pm Post subject: IIB invoking WCF "web service" |
 |
|
Novice
Joined: 10 Jul 2009
Posts: 18
Location: Monterrey, Mexico
|
Hi guys,
I have a problem invoking a WCF "web service" that works perfectly with a .Net client.
The problem comes as the service comes with a policy set definition and I'm not pretty sure but I think the IIB is not compatible:
| Code: |
<wsp:Policy wsu:Id="WSHttpBinding_IWSConsultaEdoOD_policy">
<wsp:ExactlyOne>
<wsp:All>
<sp:SymmetricBinding xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy">
<wsp:Policy>
<sp:ProtectionToken>
<wsp:Policy>
<sp:SecureConversationToken sp:IncludeToken="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/AlwaysToRecipient">
<wsp:Policy>
<sp:RequireDerivedKeys/>
<sp:BootstrapPolicy>
<wsp:Policy>
<sp:SignedParts>
<sp:Body/>
<sp:Header Name="To" Namespace="http://www.w3.org/2005/08/addressing"/>
<sp:Header Name="From" Namespace="http://www.w3.org/2005/08/addressing"/>
<sp:Header Name="FaultTo" Namespace="http://www.w3.org/2005/08/addressing"/>
<sp:Header Name="ReplyTo" Namespace="http://www.w3.org/2005/08/addressing"/>
<sp:Header Name="MessageID" Namespace="http://www.w3.org/2005/08/addressing"/>
<sp:Header Name="RelatesTo" Namespace="http://www.w3.org/2005/08/addressing"/>
<sp:Header Name="Action" Namespace="http://www.w3.org/2005/08/addressing"/>
</sp:SignedParts>
<sp:EncryptedParts>
<sp:Body/>
</sp:EncryptedParts>
<sp:SymmetricBinding>
<wsp:Policy>
<sp:ProtectionToken>
<wsp:Policy>
<mssp:SslContextToken sp:IncludeToken="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/AlwaysToRecipient" xmlns:mssp="http://schemas.microsoft.com/ws/2005/07/securitypolicy">
<wsp:Policy>
<sp:RequireDerivedKeys/>
</wsp:Policy>
</mssp:SslContextToken>
</wsp:Policy>
</sp:ProtectionToken>
<sp:AlgorithmSuite>
<wsp:Policy>
<sp:Basic256/>
</wsp:Policy>
</sp:AlgorithmSuite>
<sp:Layout>
<wsp:Policy>
<sp:Strict/>
</wsp:Policy>
</sp:Layout>
<sp:IncludeTimestamp/>
<sp:EncryptSignature/>
<sp:OnlySignEntireHeadersAndBody/>
</wsp:Policy>
</sp:SymmetricBinding>
<sp:SignedSupportingTokens>
<wsp:Policy>
<sp:UsernameToken sp:IncludeToken="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/AlwaysToRecipient">
<wsp:Policy>
<sp:WssUsernameToken10/>
</wsp:Policy>
</sp:UsernameToken>
</wsp:Policy>
</sp:SignedSupportingTokens>
<sp:Wss11>
<wsp:Policy/>
</sp:Wss11>
<sp:Trust10>
<wsp:Policy>
<sp:MustSupportIssuedTokens/>
<sp:RequireClientEntropy/>
<sp:RequireServerEntropy/>
</wsp:Policy>
</sp:Trust10>
</wsp:Policy>
</sp:BootstrapPolicy>
</wsp:Policy>
</sp:SecureConversationToken>
</wsp:Policy>
</sp:ProtectionToken>
<sp:AlgorithmSuite>
<wsp:Policy>
<sp:Basic256/>
</wsp:Policy>
</sp:AlgorithmSuite>
<sp:Layout>
<wsp:Policy>
<sp:Strict/>
</wsp:Policy>
</sp:Layout>
<sp:IncludeTimestamp/>
<sp:EncryptSignature/>
<sp:OnlySignEntireHeadersAndBody/>
</wsp:Policy>
</sp:SymmetricBinding>
<sp:Wss11 xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy">
<wsp:Policy/>
</sp:Wss11>
<sp:Trust10 xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy">
<wsp:Policy>
<sp:MustSupportIssuedTokens/>
<sp:RequireClientEntropy/>
<sp:RequireServerEntropy/>
</wsp:Policy>
</sp:Trust10>
<wsaw:UsingAddressing/>
</wsp:All>
</wsp:ExactlyOne>
</wsp:Policy>
|
The SOAP request made from the .net client is the following:
| Code: |
<s:Envelope xmlns:s="http://www.w3.org/2003/05/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="_4">http://schemas.xmlsoap.org/ws/2005/02/trust/RST/SCT
</a:Action>
<a:MessageID u:Id="_5">urn:uuid:e2592c02-8b1b-44eb-978e-5017211b2a11
</a:MessageID>
<a:ReplyTo u:Id="_6">
<a:Address>http://www.w3.org/2005/08/addressing/anonymous</a:Address>
</a:ReplyTo>
<a:To s:mustUnderstand="1" u:Id="_7">http://localhost:8283/WSConsultaEdoOD.svc/username
</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">
<u:Timestamp u:Id="uuid-1f366deb-5900-4be7-80eb-1357ad05ca45-27">
<u:Created>2014-06-17T22:48:44.955Z</u:Created>
<u:Expires>2014-06-17T22:53:44.955Z</u:Expires>
</u:Timestamp>
<c:SecurityContextToken u:Id="uuid-9187a8d5-00ed-4eb6-8ea1-3868a47e2342-1"
xmlns:c="http://schemas.xmlsoap.org/ws/2005/02/sc">
<c:Identifier>urn:uuid:73115de0-5d62-47da-a47a-64802f1ebb5e</c:Identifier>
</c:SecurityContextToken>
<c:DerivedKeyToken u:Id="_0"
xmlns:c="http://schemas.xmlsoap.org/ws/2005/02/sc">
<o:SecurityTokenReference>
<o:Reference ValueType="http://schemas.xmlsoap.org/ws/2005/02/sc/sct"
URI="#uuid-9187a8d5-00ed-4eb6-8ea1-3868a47e2342-1" />
</o:SecurityTokenReference>
<c:Offset>0</c:Offset>
<c:Length>24</c:Length>
<c:Nonce>1np5LtcSrpUdqCUvJ2hjiQ==</c:Nonce>
</c:DerivedKeyToken>
<c:DerivedKeyToken u:Id="_1"
xmlns:c="http://schemas.xmlsoap.org/ws/2005/02/sc">
<o:SecurityTokenReference>
<o:Reference ValueType="http://schemas.xmlsoap.org/ws/2005/02/sc/sct"
URI="#uuid-9187a8d5-00ed-4eb6-8ea1-3868a47e2342-1" />
</o:SecurityTokenReference>
<c:Nonce>yRbJU1kzhLRN6le9Z8Mdww==</c:Nonce>
</c:DerivedKeyToken>
<e:ReferenceList xmlns:e="http://www.w3.org/2001/04/xmlenc#">
<e:DataReference URI="#_3" />
<e:DataReference URI="#_8" />
<e:DataReference URI="#_9" />
</e:ReferenceList>
<e:EncryptedData Id="_9"
Type="http://www.w3.org/2001/04/xmlenc#Element" xmlns:e="http://www.w3.org/2001/04/xmlenc#">
<e:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes256-cbc" />
<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
<o:SecurityTokenReference>
<o:Reference ValueType="http://schemas.xmlsoap.org/ws/2005/02/sc/dk"
URI="#_1" />
</o:SecurityTokenReference>
</KeyInfo>
<e:CipherData>
<e:CipherValue>Datos cifrados......</e:CipherValue>
</e:CipherData>
</e:EncryptedData>
<e:EncryptedData Id="_8"
Type="http://www.w3.org/2001/04/xmlenc#Element" xmlns:e="http://www.w3.org/2001/04/xmlenc#">
<e:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes256-cbc" />
<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
<o:SecurityTokenReference>
<o:Reference ValueType="http://schemas.xmlsoap.org/ws/2005/02/sc/dk"
URI="#_1" />
</o:SecurityTokenReference>
</KeyInfo>
<e:CipherData>
<e:CipherValue>Datos cifrados....</e:CipherValue>
</e:CipherData>
</e:EncryptedData>
</o:Security>
</s:Header>
<s:Body u:Id="_2">
<e:EncryptedData Id="_3"
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#aes256-cbc" />
<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
<o:SecurityTokenReference
xmlns:o="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
<o:Reference ValueType="http://schemas.xmlsoap.org/ws/2005/02/sc/dk"
URI="#_1" />
</o:SecurityTokenReference>
</KeyInfo>
<e:CipherData>
<e:CipherValue>Datos Cifrados...=</e:CipherValue>
</e:CipherData>
</e:EncryptedData>
</s:Body>
</s:Envelope>
|
I configured a policy set and a policy binding but my soap request was completely different. My soap response message is the following:
| Code: |
Text:CHARACTER:The message could not be processed. This is most likely because the action 'http://xxxxxx' is incorrect or
because the message contains an invalid or expired security context token or because there is a mismatch between bindings. The
security context token would be invalid if the service aborted the channel due to inactivity.
To prevent the service from aborting idle sessions prematurely increase the Receive timeout on the service endpoint's binding.
lang:CHARACTER:en-US
|
The reason i don't show the soap request is because i've tried a lot of configurations and at the end of the day I have't got this structure:
| Code: |
<c:SecurityContextToken u:Id="uuid-9187a8d5-00ed-4eb6-8ea1-3868a47e2342-1"
xmlns:c="http://schemas.xmlsoap.org/ws/2005/02/sc">
<c:Identifier>urn:uuid:73115de0-5d62-47da-a47a-64802f1ebb5e</c:Identifier>
</c:SecurityContextToken>
<c:DerivedKeyToken u:Id="_0"
xmlns:c="http://schemas.xmlsoap.org/ws/2005/02/sc">
<o:SecurityTokenReference>
<o:Reference ValueType="http://schemas.xmlsoap.org/ws/2005/02/sc/sct"
URI="#uuid-9187a8d5-00ed-4eb6-8ea1-3868a47e2342-1" />
</o:SecurityTokenReference>
<c:Offset>0</c:Offset>
<c:Length>24</c:Length>
<c:Nonce>1np5LtcSrpUdqCUvJ2hjiQ==</c:Nonce>
</c:DerivedKeyToken>
|
I think is not possible to configure the fields from "http://schemas.xmlsoap.org/ws/2005/02/sc" such as SecurityContextToken and DerivedKeyToken.
If i want to test this "web service" using SOAP UI i get the same response, and it seems that the solution is to disable the security veritication in the WCF server application and that's not possible right now.
Does anyone knows how to get those fields using policy sets or the PEP node.
Any other options?
I'm using IIBv9.0.0.1 on Linux Red Hat.
_________________
"The problem with people who have no vices is that generally you can be pretty sure they're going to have some pretty annoying virtues." |
|
| Back to top |
|
 |
| Vitor |
| Posted: Thu Jun 19, 2014 4:57 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
We've had the devil's job either calling a WCF "web service" or something with WCF calling a web service hosted on our side; all of the problems have been in the area of WS-Security and Micrsoft's apparent belief that standards are for wimps & are more guidelines....
Under WMBv7 we got the .NET people to (grudgingly) write a ton of custom .NET to workaround this. Under IIBv9 we use the .NET nodes as endpoints into the WCF world.
Yes, yes, I know..... 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| salvador.wbi |
| Posted: Thu Jun 19, 2014 7:59 am Post subject: Reply |
|
|
Novice
Joined: 10 Jul 2009
Posts: 18
Location: Monterrey, Mexico
|
Vitor!
Once again, thank you for your reply.
| Quote: |
Under IIBv9 we use the .NET nodes as endpoints into the WCF world.
|
You my lucky boy, in our case, there's no chance to do that, probably the work around will be to disable the security (hoping that the .net service is within the dmz) or probably we will have to develop a proxy service. 
_________________
"The problem with people who have no vices is that generally you can be pretty sure they're going to have some pretty annoying virtues." |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Jun 19, 2014 8:04 am Post subject: Re: Reply |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| salvador.wbi wrote: |
| You my lucky boy, in our case, there's no chance to do that |
Urgh.
It wasn't easy here; we run IIB on AIX. I was forced to "obtain" access to one of our BizTalk servers that wasn't doing anything useful (just running BizTalk or something) and put a standard edition IIB on it.
More hops, more places to fail, more license and some irritated BizTalk people who probably won't send me a Christmas card this year. That I would want to open without taking a lot of precautions.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Fri Jun 20, 2014 2:19 am Post subject: Re: Reply |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
| Vitor wrote: |
More hops, more places to fail, more license and some irritated BizTalk people who probably won't send me a Christmas card this year. That I would want to open without taking a lot of precautions. |
Why? Did you accidentally on purpose remove BizTalk from the Server or something?
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Jun 20, 2014 4:55 am Post subject: Re: Reply |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| smdavies99 wrote: |
Why? Did you accidentally on purpose remove BizTalk from the Server or something?
|
I would never sully myself with such tactics.
I just correctly guessed the Administrator password, and refused to tell them what I changed it to.....
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| salvador.wbi |
| Posted: Fri Jun 20, 2014 7:08 am Post subject: |
|
|
Novice
Joined: 10 Jul 2009
Posts: 18
Location: Monterrey, Mexico
|
| Quote: |
Why? Did you accidentally on purpose remove BizTalk from the Server or something?
|
It sounds more like the BizTalk team don't like to share their servers, that happens very often.
Probably they will believe that you are telling them - Hey guys! we don't need BizTalk anymore 
_________________
"The problem with people who have no vices is that generally you can be pretty sure they're going to have some pretty annoying virtues." |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Jun 20, 2014 7:20 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| salvador.wbi wrote: |
| It sounds more like the BizTalk team don't like to share their servers, that happens very often. |
The amount of power BizTalk takes to run, I can beleive that.
| salvador.wbi wrote: |
| Probably they will believe that you are telling them - Hey guys! we don't need BizTalk anymore |
They should believe that - it's not just me telling them that.....
(For the record and in the interests of balance I am compelled to state that this Windoze product has additional features which means it can't be directly replaced with IIB alone. It can however be replaced with a suite of IBM & other vendor's products which is the strategic plan at this particular site. Hence a blind eye being turned to my piracy)
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
