I'm trying to figure out how to use integrated windows authentication within a Geo-processing service. My python script is using the ArcGIS Api for python. I created this short script on my local machine where my 'Wndows Credentials' exist. All I'm doing is instantiating the GIS object by passing it my <domain name>/portal/sharing/rest. After, I simply print out my username exactly how the documentation suggest
print("\n\nIntegrated Windows Authentication using NTLM or Kerberos") gis = GIS("https://portalname.domain.com/webcontext") print("Logged in as: " + gis.properties.user.username)
Integrated Windows Authentication using NTLM or Kerberos Logged in as: username@DOMAIN
I then convert this to a Geo-processing service and publish this to my Arc Server. The problem is, the server doesn't have my user credentials that it gets from IWA, so it isn't able to run successfully. My goal is to eventually hit this geo-processing service from our web application built with the Esri JS Api, which allows me to get the users credentials with the IdentityManager.getCredentials() JS function call.
Do you all have any suggestions on how to create the python GIS object within a Geo-processing service with IWA authentication? I think my web app would ultimately pass these credentials to the Geo-processing service?
Can you tell us a little bit more about what you're trying to do? What else is the GP service supposed to do? I understand if you can't share much more.
The gp service would hit one of our map services to return back some data based on a query from the user. For example:
gis = GIS("https://<domain>/portal/sharing/rest")
print("Logged in as: " + gis.properties.user.username)
map_service_item = gis.content.get("123abc")#(MapServer)
myLayer = Layer.fromitem(map_service_item, 0)
query_result1 = myLayer.query(where=COL1<3', out_fields='COL1')
It sounds to me like the better, more direct approach is to perform the required query in the JS application. Is that not an option?
My goal is to take the actual data that comes back from the query and save it to an ASCII file on the server for the user to then download.
So in order to launch this file creation, I was going to send the gp service the query parameter in order create to that file. Once the gp service is complete the user could download that file. The file could be fairly large and may take some time to create.
Oh, okay. Does the service point to a database accessible to the ArcGIS Server? Another option might be an arcpy script to generate data via the database.
Yes, the service points to a database accessible by Arc Server.
We do have arcpy scripts that access the database, but I just really liked the features offered by the ArcGIS api for python.
Accessing the database directly is likely the more efficient route in this case, especially since it seems many records are returned sometimes. If the main benefit of using the API is to do manipulations with pandas or something like that, you can also just do this by accessing the database directly. A related question was just asked the other day on how to load a feature class into a dataframe, for example: Re: Stand-Alone Table to Pandas Data Frame - Esri Community
Anyhow, if you must use the ArcGIS API for Python I think the place you have to start is making sure the account running your ArcGIS Server has its own account in Portal with adequate permissions.
So, we use an Oracle database. If I wanted to connect to Oracle without Arcpy, I would use the python library Oracledb. Extra libraries, such as Oracledb, aren't really an option for us. We are sticking to what strictly comes with the python in Arc pro.
Anyways, I wanted to let you know that I actually had the GIS object intializing correctly when I uploaded it as a gp service. The issue was that I was trying to return the username from the GIS object and of course, as you mentioned, there was none so it threw an error when I attempted to return the username like so: gis.properties.user.username
Even though it wasn't able to get a username I was still able to get an item from the portal with the GIS object. The fault turned out to be my own. I'll see about registering the account running Arc Server with the portal, but I don't really see a need now since access to this gp service is managed by groups in portal.