Error calling Java web service from .NET code?

I'm getting an error in code that calls a Java web service. The code works fine on the rest of my team's PCs. I have exactly the same copy of the source code. So I'm guessing it's a configuration issue on my PC buried deep somewhere and has nothing to do with the source code itself?

The error I get is:

The HTTP request was forbidden with client authentication scheme 'Anonymous'

Here are the 2 configuration sections from the web.config.

<binding
  name="SEITokenServiceBinding"
  closeTimeout="00:01:00"
  openTimeout="00:01:00"
  receiveTimeout="00:10:00"
  sendTimeout="00:01:00"
  allowCookies="false"
  bypassProxyOnLocal="false"
  hostNameComparisonMode="StrongWildcard"
  maxBufferSize="65536"
  maxBufferPoolSize="524288"
  maxReceivedMessageSize="65536"
  messageEncoding="Text"
  textEncoding="utf-8"
  transferMode="Buffered"
  useDefaultWebProxy="true">
  <readerQuotas
    maxDepth="32"
    maxStringContentLength="8192"
    maxArrayLength="16384"
    maxBytesPerRead="4096"
    maxNameTableCharCount="16384" />
  <security
    mode="None"/>
</binding>
<client>
    <endpoint
      address="http://10.1.1.1:8180/tokenService"
      binding="basicHttpBinding"
      bindingConfiguration="SEITokenServiceBinding"
      contract="TokenService.SEITokenService"
      name="SE开发者_开发百科ITokenServicePort">
      <identity></identity>
    </endpoint>
</client>

I have seen this issue before in my work place. It may be totally different for you, but I will share my expereince.

In my scenario, it was to do with a different group policy being applied to one of the development PC's and not to all the other development PC's, which resulting in the current users credentials not being passed to the internal proxy server.

I would recommend trying to explicitly set an identity for the service in the web.config (maybe your own userid) and see if that resolves the issue.

That however is only a temporary solution, you need to discover the difference in the group policies and have them amended so that the staging / development systems are all the same.

Don't know the answer, but a good way to debug it would be to run a debugging http proxy like Fiddler on your machine. Grab the http conversation and diff it with the output from a colleague's machine that does not exhibit the issue.

This was due to an IP subnet restriction on the java web service server.