Geoprocessing Service Authentification

[JeromeCauchon]

Hi,
   I want to consume a Geoprocessing service using ArcGIS Runtime SDK for Java. My service needs to be authenticated so i set the UserCredentials of the Geoprocessor. I always receive this error. Somebody have an idea?

Jul 18, 2013 12:45:34 PM org.apache.http.impl.client.AbstractAuthenticationHandler selectScheme
WARNING: Authentication scheme ntlm not supported
Jul 18, 2013 12:45:34 PM org.apache.http.impl.client.DefaultRequestDirector handleResponse
WARNING: Authentication error: Unable to respond to any of these challenges: {ntlm=WWW-Authenticate: NTLM, negotiate=WWW-Authenticate: Negotiate}
com.esri.core.io.EsriSecurityException: Invalid or missing user credentials
at com.esri.core.internal.io.handler.l.a(Unknown Source)
at com.esri.core.internal.io.handler.l.a(Unknown Source)
at com.esri.core.tasks.ags.geoprocessing.b.b(Unknown Source)
at com.esri.core.tasks.ags.geoprocessing.b.a(Unknown Source)
at com.esri.core.tasks.ags.geoprocessing.b.execute(Unknown Source)
at com.esri.core.internal.tasks.b.call(Unknown Source)
at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)
at java.util.concurrent.FutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: com.esri.core.io.EsriServiceException: Unauthorized
at com.esri.core.internal.io.handler.c.a(Unknown Source)
at com.esri.core.internal.io.handler.l$1.handleResponse(Unknown Source)
at com.esri.core.internal.io.handler.l$1.handleResponse(Unknown Source)
at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:735)
at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:709)
at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:700)
at com.esri.core.internal.io.handler.l.a(Unknown Source)
... 10 more

[MarkBaird]

I guess some more information is needed to diagnose this.

- How is your ArcGIS Server configured in terms of security?  Are you using token based security?  Does your server use windows authentication against the services via IIS?  I'm thinking that windows authentication comes into the picture from the error messages.

- What is you client running on?  Is it a Windows machine connecting to a Windows Server based ArcGIS Server?

- What does your code look like?

- From the client, if you open up a browser window, can you browse the service endpoint for the geoprocessor?

If you are using token based security (which is the most common authentication I see), you set up your user credentials with a username / password and when you create your GeoProcessing class, you use the constructor which takes the sevice AND the user credentials.  In the background you will receive an access token for the service which is used each time you make a request.

Mark

[JeromeCauchon]

Thanks for reply. Here is more details about my issue :

- How is your ArcGIS Server configured in terms of security? Are you using token based security? Does your server use windows authentication against the services via IIS? I'm thinking that windows authentication comes into the picture from the error messages.

I'm using Windows Domain as User/Role store and the server use windows authentification against the service in ISS.

- What is you client running on? Is it a Windows machine connecting to a Windows Server based ArcGIS Server?

I created three different clients(Javascript/Java/WPF) on a windows server 2012 machine. Only my Javascript client works. My server is a windows server 2008.

- What does your code look like?

                try {

   UserCredentials credentials = new UserCredentials();
   credentials.setUserAccount("myUser", "myPassword");
   credentials.setAuthenticationType(AuthenticationType.HTTP);
   Geoprocessor geoprocessor = new Geoprocessor(
     "http://myHost/arcgis/rest/services/GP/HLZ/GPServer/HLZ", credentials);
   List<GPParameter> gpInputParams = new ArrayList<GPParameter>();

   GPFeatureRecordSetLayer gpInputAOI = new GPFeatureRecordSetLayer(
     "Area_of_Interest");
   gpInputParams.add(gpInputAOI);

   geoprocessor.executeAsync(gpInputParams,
     new CallbackListener<GPParameter[]>() {

      @Override
      public void onError(Throwable th) {
       th.printStackTrace();

      }

      @Override
      public void onCallback(GPParameter[] result) {
      

      }
     });

  } catch (Exception e) {

  }

- From the client, if you open up a browser window, can you browse the service endpoint for the geoprocessor?

Yes but i need to enter my credentials.

I do not use token base security. Maybe it could be a workaround?

Thanks

[MarkBaird]

okay that makes it clearer.

So when you view the endpoint in a browser and it asks you for your credentials, is that FireFox?

If you open the endpoint in IE, does it authenticate you automatically?  Usually IE forwards your credentials using Windows Integrated Security.

[JeromeCauchon]

It is Chrome!

Same behavior with IE.

[MarkBaird]

I'm looking at how we've implemented NTML authentication and if it is supported at 10.1.1.

Will report back...

[MarkBaird · Accepted solution]

I've looked at this and sadly NTLM is not supported in the current 10.1.1 release.  The story is the same for the Android API too as this is shared code.

Your option here is to configure your server to use token based security as a workaround instead of using Windows Integrated (NTLM) security.

However in the interest of improving the API, I'm looking into having NTML support for the next release.

Thanks for pointing out the problem

Mark

[GeneLege]

Lack of ntlm support seems to be an issue with proxy authentication as well.

Most proxy's in use in the real world (bluecoat,) seem to require ntlm authentication, at least in their usual configurations.

We have gotten around this by setting up an httpclient ourselves and authenticating via that, but a similar approach with geoprocessing is not possible, of course.  This really should be supported by the Runtime sdk code correctly.

[MarkBaird]

Support for NTLM is definately on our radar.  In fact we have tested the UserCredentials class in our current development code and I can confirm it works against an NTLM authenticated service.  There is an additional method on the UserCredentials for settting the domain name you are using. 

This functionality is very likely to find it's way into the next release.

Mark