Invalid token while accessing UN Feature Service

[robertopepato_bizpoke]

Hi everybody, 

Context / Scenario:
I believe this is a cross-cutting concern question as it addresses authorization but since the behavior happens when trying to access a FeatureServer service from an UN feature I think that posting it here is a good idea.

We do have a federated (portal/arcgis server) ArcGIS Enterprise 11.1 environment and I'm trying to list the layers (e.g. /layers endpoint) of a given FeatureServer originating from the Electric UN Foundation Model Electric Utility Network Map publishing. 

Problem:
When accessing the FeatureServer /layers endpoint for listing the layers of a given feature server (e.g  https://<<www.somefancydomain.com>>/server/rest/services/Electric_Utility_Network/FeatureServer/layers?token=<<my_secret_token>>&f=json) using a token generated through portal /generateToken endpoint (e.g. https://<<www.somefancydomain.com>>/portal/sharing/rest/generateToken), the result is "Invalid Token" (tested with several different credentials, all of them with valid ArcGIS Utility Network licenses). The behavior happens no matter how we pass the token in the request - I tried using querystring, authorization bearer header, and X-Esri-Authorization header and it fails every time.
IMPORTANT: The behavior only happens if we set the Client parameter of the Generate Token endpoint as "IP Address" (in this case, I did use my public IP Address) or "IP Address of this request's origin". If we use the "Webapp URL" option instead and set a domain there, even a made-up one, then everything works as expected.

I was able to reproduce the same behavior using different clients like the browser, postman, curl, python, and javascript requests.I'm not sure if this is the expected behavior, but it didn't make much sense to me.

Steps to Reproduce:
1. Go to your portal and generate a token using either "IP Address" or "IP Address of this request's origin" as the client parameter
2. Log out from your browser and execute a request against the /layers endpoint of your UN feature server by adding the token obtained in step #1 and the f=pjson parameters.

It looks like people experienced similar behavior and perceptions in this old post in stackexchange: https://gis.stackexchange.com/questions/223464/how-do-i-obtain-a-valid-token-for-updating-layer-defi...

Does anyone else experienced issues when using IP strategies for obtaining the token and using it later to get access to protected items/services?

Thanks,

========================================================================ReqRequest with token generate using "IP Address of this request's origin":

Exact same request but token was obtained using a made up url in the "Webapp URL" parameter:

[MikeMillerGIS]

Guess throwing out an idea.  Since the server is federated with portal, I think you need to exchange the portal token for a server token.  

https://community.esri.com/t5/arcgis-rest-apis-and-services-questions/generate-a-token-to-query-feat...

[robertopepato_bizpoke · Accepted solution]

Hi @MikeMillerGIS , thanks for adding to the discussion!

Looking at the problem from a developer/operations experience, it looks odd to me to have a strategy for getting a token when using referer (i.e. the "Webapp URL" Client option) as the Client parameter (because as stated on the links that you and I shared, it works when using referer as the client parameter) and another strategy for getting a token when using "IP Address" or "IP Address of this request's origin" as the Client parameter.

In any case, I'll experiment a little with your idea and if I have any new insight and/or conclusion, I'll share it back here later.

At least we have the option to overcome the issue: use referer as the client parameter instead of "IP Address" or "IP Address of this request's origin" (because those other options don't look like to have a predictable behavior).

Cheers