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 ? 

  • 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.