Select to view content in your preferred language

Setting shared key in Federated scenario

06-03-2018 10:47 AM
New Contributor III


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? 

0 Kudos
3 Replies
Esri Notable Contributor

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 Gu... 

0 Kudos
New Contributor III

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:

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

After  this there occurs multiple errors of this form 

DEBUG 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:

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? 

0 Kudos
New Contributor III

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: Server machine 'https://portal.<HOST>.com/portal/sharing/rest/community/self' returned an error. 'User does not exist or is inaccessible.'

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:


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.



0 Kudos