topic Re: Setting shared key in Federated scenario in ArcGIS Enterprise Portal Questions

Setting shared key in Federated scenario

SzymonPiskula1 — Sun, 03 Jun 2018 17:47:04 GMT

Hello

I have a setup of 10.6 with Portal + 2 Sites: Federated Site and Hosting Site. Each component has its own, different shared key. Should I make sure all actually have the same shared key?

Re: Setting shared key in Federated scenario

JonathanQuinn — Mon, 04 Jun 2018 22:03:41 GMT

There's no need to modify the shared key of distinct federated Server sites. You'd really only need to do that if you're setting up siloed ArcGIS Server sites, which you can't federate anyway.

Single-machine high-availability (active-passive) deployment—ArcGIS Server (Windows) Installation Guide (10.5) | ArcGI…

Re: Setting shared key in Federated scenario

SzymonPiskula1 — Tue, 05 Jun 2018 07:29:25 GMT

Thanks Jonathan. What I have observed is that if our Shared Key is different between Portal, Hosting and the Federated sites then in Server Logs i see:

DEBUG

Exception caught while validating token. Could not decrypt token. Token may not be valid.

After this there occurs multiple errors of this form

DEBUG

java.io.IOException: com.esri.arcgis.discovery.admin.security.InvalidTokenException: com.esri.arcgis.discovery.admin.security.AGSSecurityException: com.esri.arcgis.discovery.admin.security.AGSSecurityException: Server machine 'https://portal.<HOST>.com/portal/sharing/rest/community/self' returned an error. 'User does not exist or is inaccessible.'

If I set the keys to be the same the above go away.

I observe this when I acquire a (portal exchanged) token via the DotNet proxy & AppID and AppSecret and make calls with the token to access resources on ArcGIS Server Federated site, where our maps are. I have set up an Application as a Portal Item under the (SAML) account that owns some map services in the Mapping Federated site. When i try to reach to that mapping service via the proxy (and the AppID) I do get the token itself generated OK, but it is detected as invalid:

DEBUG

Exception caught while validating token. Invalid token.

What I think that also might be important is that our system uses SAML. Even if i use an Application that was created as Portal primary Site Admin this still does not work.

If the shared keys dont need to be the same how can the Federated Site decrypt the token?

Re: Setting shared key in Federated scenario

SzymonPiskula1 — Tue, 05 Jun 2018 09:32:41 GMT

After some investigation I am thinking now that it is crucial that the shared keys are different.

IF the shared keys are the same i think that server performs different validation:it acts as if token was generated by server itself, hence expects different token structure (can be seen after token decryption)

IF keys are different then debug logs of the Federated Server DO report an error, but then pass on to the section that causes this error:

This could mean that the token is passed back by server internally to portal (where original encryption has happened, with the different key). Only then Portal decides if the token is valid or not.

For reason i cannot determine my tokens generated with AppID get rejected with

'User does not exist or is inaccessible.'

After token (not acces_token, but the one that my proxy uses to talk to server!) decryption I can see that it contains:

{"s":"9f22","t":"a","c":1528196962495,"d":"<Federated-Site-Id>","e":true,"g":"<App-ID>","h":"0123456789ABCDEF","l":0,"m":0}

Federated-Site-Id IS the ArcGIS Server site that is federated with my portal and that i try to reach, so it matches overall logic. This has no user info though, i suppose <AppID> plays its role?

After seeing the above error in Server Logs, I cannot see any meaningful error in Portal logs that would indicate a crash or so.

Am I missing some settings on the Application? I have shared it with everyone but did not help.

Regards,

Szymon