Adjusting Existing Applications to Accomodate a First Time Portal Environment with Federation

[osswmi]

My organization is in the process of setting up a new ArcGIS Server Enterprise environment where we are using ArcGIS Portal for the first time as well. We are coming from a 10.6.1 setup where all of the secured mapping applications are using the ArcGIS Server Managers built-in security model where we create roles, users and restrict access to folders using the defined roles. We have a mix of both in-house built JavaScript applications and applications built by outside vendors that use secured services. We are currently using the Identity Manager JavaScript code shown below to register an obtained token with our JavaScript applications and it works seamlessly.

namespace.IdentityManager.registerToken({
	expires: namespace.VueModel.ArcGISToken.expires,
	token: namespace.VueModel.ArcGISToken.token,
	ssl: true,
	userid: "username",
	server: "https://gis.server.com/publicgis/rest/services"
});

In the 10.9.1 setup we are currently building, we were under the impression that federation was the way to go but now we are seconding guessing ourselves on that decision as it seems the ability to maintain compatibility with our existing apps is non-existent in two different ways.

The first is that even though we are able to obtain a token from the Portal URL shown below, we are still getting prompted to sign in when our app loads even thought the token is supplied to the same code above when calling the "registerToken" method above. We are not sure if we have to switch to oAuth here and if so, while we could do it, our vendor supplied products, at least in the current form, won't be able to adapt.

https://gis.server.com/portal/sharing/rest/generateToken

The second issue at hand is dealing with existing feature services. As it currently stands, our feature editing services are protected by the built-in security model of ArcGIS server manager. However, we noticed that in order to establish a feature service in the new setup, it eats up one of our very limited "creator" licenses which we are really trying to avoid.

Based on what we have encountered, is federation a no go for our use case, or does someone have code and/or documentation that would explain how to address the two items mentioned above.

[osswmi · Accepted solution]

So after making a call to ESRI support, we were able to resolve both of the issues mentioned in the original post, so I will post the answer to both items below.

For the item relating to token security, while the path to generate the token at the URL above was correct, the option for which "Client" method to use was not. We had been using the option for "IP Address" but were instructed by our ESRI support specialist to use "Webapp URL". With this option, you can be as granular or as open on your URL as you desire, so if you wish to access multiple map services/items in the same folder, you can stop the URL at the containing folder level, or drill down as deep as you need to the "Map/Feature Server" level.

For the item relating to feature editing services, a "Creator" license is not required for apps to consume the service and make data edits. This helps prevent eating up a creator license. We have tested and verified this in our new setup.

 Regards.