It is strongly recommended that users who want to integrate the GeoEvent Extension and Portal for ArcGIS in the same environment use the most recent release of the ArcGIS product. GeoEvent’s integration with Portal is not supported prior to the 10.4 product release. Some users have successfully deployed these products using earlier releases, however, their deployments have significant functional limitations and known constraints. GeoEvent first began integrating Portal’s updated security model at the 10.4 release; integration was completed with the 10.4.1 product release. This blog clarifies GeoEvent’s integration with Portal, provides detail on how the integration works, when and why it was implemented the way it was, and suggests some considerations you should be aware of when planning a deployment.
How Integration Works
When we discuss integration between GeoEvent and Portal, we're really talking about two different issues.
The first involves security and access to the GeoEvent Manager. As the product name implies, GeoEvent is an extension for ArcGIS Server. Beginning with the 10.3 release of both products, GeoEvent uses the same security store as ArcGIS Server. What that means in practical terms is that when logging into the GeoEvent Manager to configure inputs, outputs, and services, you do so using an administrative account for ArcGIS Server. It is recommended that you use Server’s default Primary Site Administrator (PSA) account, but any administrative account – such an Integrated Windows Authentication (IWA) admin account – can be used. Once inside the GeoEvent Manager web application the user experience is the same regardless of which administrative account was used to gain access.
When ArcGIS Server has been federated with Portal for ArcGIS, it gives up its own security store and relies on Portal to authenticate and authorize user access. This means that GeoEvent, in turn, will also rely on Portal’s security model since GeoEvent is using the same security model used by ArcGIS Server.
The second issue involves access to data. GeoEvent uses server connections, registered as GeoEvent Data Stores, to connect to server machines and request access to data. When registering a server connection a user provides the URL of the server they are trying to reach and, if necessary, credentials or a token to be used when accessing the server content. You can register server connections to the local ArcGIS Server (the one running the GeoEvent Extension), an external ArcGIS Server instance, an ArcGIS Online for Organizations instance, or an instance of Portal for ArcGIS (either on the local server or running on an external server).
For "FULL" Integration to be considered, both issues must be addressed. Users should be able to log into GeoEvent Manager using the Portal Security Store, AND be able to access any potential data source coming from Portal for ArcGIS.
When and Why Was This Implemented?
As indicated earlier, GeoEvent is an extension to the ArcGIS Server product. A decision was made at the 10.3 release that GeoEvent should use a token-based security model, similar to what ArcGIS Server uses, to simplify access control as well as the user login experience. This worked by passing an administrative user's credentials to ArcGIS Server and receiving back an encrypted token which verified the user's access, limited which server / site could use that token, and imposed an expiration date after which connections using the token would no longer validate. This worked well for ArcGIS Server in that GeoEvent could easily log in using those same credentials, and could use a Long Term Token to validate access to all of Server's services through the Data Store for the life of that token, up to one year.
When configured with built-in users, Portal's security worked the same way. Users would provide credentials at the login page for the GeoEvent Manager which GeoEvent would use to request a token from Portal on behalf of the user. When IWA had been configured this approach required users to first use Portal’s Token generation page to obtain a token (by entering credentials recognized by Portal) and then entering that token into the GeoEvent Manager’s login page.
This exposed a crucial difference between Server tokens and Portal tokens – specifically the maximum time a token could be used before it expired. While Server allowed tokens to be created which would not expire for a year, Portal only supported tokens with a maximum life of up to two weeks. This wasn’t a significant limitation for a user’s login to GeoEvent Manager, but it meant that GeoEvent Data Stores would need to be reconfigured with a new token every two weeks.
At the 10.4 release Portal updated the federation experience with ArcGIS Server, providing an opportunity for GeoEvent to improve its integration and utilize the same OAuth2 security model. Portal security integration was completed with the GeoEvent 10.4.1 product release. This removed the need to have different login workflows to authenticate built-in and IWA users, and more importantly removed restrictions inherent with the token-based access developed for the 10.3 / 10.3.1 releases of GeoEvent. Within the Data Store, users could choose to enter credentials which GeoEvent would encrypt and use to authenticate requests it made to either Server or Portal. These changes addressed both issues identified above streamlining a user’s login to GeoEvent Manager and providing long term access to Portal data and resources.
GeoEvent deployment into a federated environment with Portal prior to 10.4 is not supported by Esri Technical Support. While it may be possible to architect a solution using these products at the 10.3.x releases, it is against our recommended best practices. Changes made for 10.4 and 10.4.1 to replace the reliance on token-based authentication cannot be ported back to earlier releases. There will be no patches or hot fixes to re-architect the token-based security as it would involve significant modification to Portal, Server, and GeoEvent.
Users looking to leverage GeoEvent and Portal in an enterprise solution are encouraged to use the latest public release of each product as these will incorporate improvements to both the user experience and product integration.