Generate Token for url on a unfederated ArcGIS Server? (I am new at this)

[TimHayes3]

I am using ArcGIS for Server 10.6.1.

I have a third party that needs to connect their application to a REST service url used on our unfederated (stand alone) ArcGIS Server; We also have a federated ArcGIS Server. Both are behind our firewall. I have issued the third party app a username and password. Next I need to generate token from our unfederated server. Our unfederated ArcGIS Server, in ArcGIS Server Administrator Directory - Services Directory is disabled. Not sure if this will be an issue, will it?

First step I went into the ArcGIS Server Administrator Directory - security - tokens - supported operations - update and I added the longtimeout and shortimeout parameters to the JSON like so:

{
"type": "XXXXXX",
"properties": {
"sharedKey": "XXXXXXXXXXXXXXXXXXXXXXXXXXXX",
"longTimeout": "1440",
"shortTimeout": "60",
"allowHttpPostQueryParams": "true",
"allowHttpGet": "true"
}
}

I see 1440 is the minutes in a single day, since I want the connection authorized for 365 days, do I change the 1440 to 525600 (the number of minutes in 1 year)?

Using the screenshot below (from ArcGIS Server Administrator Directory) for reference, and not having done this before, I do the following:

1) enter the username

2) enter the password

3) client remains HTTP Referer

4) HTTP referer, I add the the url like so https://myname.mydomain/myservername/rest/services

5) Expiration (minutes), the connection that will use the token is intended to be long term, let's say 1 year. Do I need to enter the number of minutes in a single year in this box? (I also need to make sure that ArcGIS Server Manager - Security - Token Settings - Lifespan of Long-lived Tokens is set to 365 days, correct?)

6) Then I choose GENERATE.

Is there something else I need to do? Am I missing anything?

[MichaelJenkins · Accepted solution]

A couple of thoughts and observations. 

• Consider upgrading, since 10.6.1 is at the end of life.  Also, if anything I say below is not relevant to 10.6.1 I apologize in advance.
• You should only need to go into the admin interface if you need to change the behaviour of the generate token service, for example to enable the GET request -- only do that if absolutely necessary.
• You can generate a token without being in the admin interface -- try  https://myname.mydomain:6080/arcgis/tokens/   In this interface you will have a drop down list for token expiration that should include "1 year" (see my screenshot)
• HTTP referer should be the URL of the client that will making the request to the secured service, not the URL of the service you want them to connect to.   This is the URL of the page from which the request is made to the ArcGIS resource, and there can only be one.  This is important.  You will only be able to test it from that URL.
• To clarify, this 3rd party app is also behind youre firewall?

I hope this helps.   The http referer is likely be the main issue from what you have shown.  Good luck!

[TimHayes3]

Thank you, Michael. This is helpful. I have some more questions:

1) I am checking to see if the 3rd party app is behind our firewall; if no, then I will have their url whitelisted.

2) We are planning to upgrade to 10.9.1 within the next 12 months.

3) The token url you provided works.

Just so I am clear on what I need to do, in the ArcGIS Token Service site, I add their username & password, the referring url for HTTP referer, set the expiration to 1 year, keep the format as HTML, then hit Generate Token. With the token, anytime the username and password used with the 3rd party app are used to access our ArcGIS Resource the token will automatically be added to the url? or does it need to be copy and pasted into the url?

[MichaelJenkins]

You don't need to supply the 3rd part app with both username/pw and a token.  The token alone authorizes them to access services, and it is tied to the username that was used to generate the token, so that is how the server knows which content a user can access.

Think of it this way - if you just go to the URL to the secured map service, the server will prompt you for a username and password.  Same thing if you go to https://myname.mydomain/arcgis/rest/login.  When you log in, it generates a token for you and stores it in a cookie for your browser.  Then each time you make a request to the server, it automatically includes that token in the header.  You can't see it unless you look for it, but it is sending that token with every request to the server.  

So, the purpose of providing a token to another application is so that the appliation's user doesn't have to provide a username and password.

You could just provide the username and password to the user of that application and when that 3rd party application tries to use the map service, it will prompt them to log in, then they log in and carry on their merry way.  

It depends on what this 3rd party application can do and how many people are going to use it.  If you provide just the token, that application will need to know how to use it.  End users can't log in with the token directly.

Also, since your server is behind the firewall,  you could just leave it as an unsecured service (anonymous access) and then no username, password or token would be needed by the 3rd party app.  That is as long as it is ok for people on your network to be able to see that service if they know where it is.  Since you have services directory turned off, the URL to the service can't be found by accident.

That  may have been long winded, but I like to dig into the details. 🙂

[TimHayes3]

Thanks, again super helpful. Well, I just found out that the 3rd party will not be using their app to access our ArcGIS url behind out firewall. It will be a person logging in and downloading data from a specific REST url.  I have created a built in account for them on Portal (username and password). They have been provided with our ArcGIS REST services url (down to a specific REST service); They only need to access this REST url and download data. They would access it via using their username and password created in Portal. But, when they access the REST url they get a 403 error (forbidden to access). This tells me it may be more related to our firewall settings, not an ArcGIS thing.

Here is some additional information in list format:

1) The person needs to access an ArcGIS REST url that is behind our firewall using their Portal username and password. They need this access in order to download some data.

2) On the standalone ArcGIS Server they will access the REST url , the services directory is disabled. 

Here is what I think I need to do, let me know if I am on the right track:

- Set up a VPN account for the user limiting their access to only the ArcGIS REST url from which they will download data. I think this is all done on the VPN/Firewall side, but is there anything I need to change in ArcGIS Server other than maybe Generate Token based on IP Address, not HTTP Referer? (I was told I need to keep the services directory disabled)

- In these circumstances, if I need to generate a token would I change the Client from HTTP Referer to IP? This would issue a token to a specific IP address the person can access the REST url from that IP address?

[MichaelJenkins]

They will need to access more than just the specific map service URL, because they will need to be able to log in and that involves a couple of other URLs on the server. At a minimum they also need to be able to access https://myname.mydomain/arcgis/rest/login

If by "Portal account" you mean ArcGIS Enterprise Portal, then that won't work for services on an unfederated server.  But if you just mean a built in account on the unfederated server, then yes I think that would work. 

You can create a group, using ArcGIS Server Manager, add that user to the group, then secure the service, specifiying that group has access.   Then, any user account in that group can see/access the service (plus all admin accounts), even if it is just one user.

No other changes to ArcGIS server related to the VPN/Firewall as far as I know.  No token needed since they will generate their own when they log in.