Consuming C# WCF service from managed visual cobol winform application

I was able to execute the sample visual cobol WEB WCF service and validate its results.

I am trying to consume a C# WCF service hosted in a different domain from a winform test client managed program developed using VC 2.3.

I get error message  "The server has rejected the client credentials".

Here's my test client app config file details...

 

<client>

<endpoint address="net.tcp://servername.domain:port number/path/TestService.svc" binding="netTcpBinding" bindingConfiguration="TestService" contract="ServiceReference.ITestService" name="TestService">
<identity>
<userPrincipalName value="service account@another domain" />

</identity>
</endpoint>
</client>

 

What am i missing ? 

#WCF
#VisualCobolManaged

This is a WCF issue, not a Micro Focus one. You'd have the same problem if your client was written in C#.

Note that it's not a WCF bug, just a feature of WCF which is working as intended but complicates service invocation. WCF wants to secure services by default, because remote service invocation is a security risk.

The server is rejecting the request because it can't authenticate the client.

As I understand it (and I'm not a WCF expert), when a client uses an identity element containing a userPrincipalName, the client will attempt to authenticate to the server with Kerberos. That will only work if the client and server share a Kerberos domain, which (again, as I understand it) for Windows generally means either they're in the same domain, or their domains are part of a federated forest.

See these StackOverflow discussions for additional information:
stackoverflow.com/.../what-purpose-does-the-wcf-client-specified-userprincipalname-serve
stackoverflow.com/.../the-server-has-rejected-the-client-credentials

The Microsoft WCF documentation:
docs.microsoft.com/.../index

goes into WCF security in great detail. From a quick review, I think you may have to use WSHttpBinding rather than NetTcpBinding to authenticate to a remote service that's not in your Kerberos domain. I'm not at all sure about that, though.

I suggest contacting the person or organization responsible for the remote service. Presumably they have dealt with this before.