Securing services

The security and sharing model used by ArcGIS Server is different than that used by Portal for ArcGIS. How you want to secure and share services is a primary consideration when deciding to federate.

Federation integrates the Enterprise portal security and sharing model with an ArcGIS Server site. Once federated, you no longer use ArcGIS Server Manager to control permissions and secure services. Service access permission and service layer sharing properties are updated in the Enterprise portal content item manager.

An ArcGIS Server that is not federated with an Enterprise portal uses a built-in identity store to manage authentication and authorization. Services you publish that are not specifically secured in Server Manager are publicly discoverable by any client with access to the server's REST Services Directory.

Enterprise portal content items, as opposed to ArcGIS Server web services, are owned by a named user. Unless specifically shared with other Enterprise portal members, such as those organized into a group, content items added to the Enterprise portal are only accessible by the content item owner.

For more information on ArcGIS Server and Portal for ArcGIS security and sharing, refer to the following topics:

• Configure server-tier authentication
• Integrate your portal with ArcGIS Enterprise
• Federate an ArcGIS Server site with your portal
• Services and portal items
• Share items

Single sign-on

Federation provides users with a single sign-on (SSO) experience. Users, usually in the context of a web session, are not prompted to re-enter their credentials. When federated, opening a new tab to launch ArcGIS GeoEvent Manager in an existing authenticated session facilitates automatic sign in to GeoEvent Manager.

In some cases, system administrators may choose not to federate to separate administration of the Enterprise portal from the configuration of GeoEvent Server. By doing so, a named user assigned the role of administrator for the Enterprise portal would not be able to use those same credentials to sign in and perform administrative actions in GeoEvent Manager.

Spatiotemporal data store

ArcGIS GeoEvent Server requires a registered ArcGIS Enterprise type server connection to an Enterprise portal to discover whether a spatiotemporal data store is registered with the Enterprise portal's hosting server. Federation is not required to access a spatiotemporal data store. When federated, the default server connection in GeoEvent Server points to the Enterprise portal, making discovery and use of a spatiotemporal data store more automatic.

Some system administrators may prefer to have the default server connection in GeoEvent Server address the local, or real-time, server. They prefer to decide whether the use case they are configuring can be supported by a traditional relational database or whether it requires use of the spatiotemporal data store and choose a connection registered with the Enterprise portal if they specifically intend to access its spatiotemporal data store. This approach is only possible in a nonfederated environment.

For more information on the spatiotemporal data store, see Manage spatiotemporal data stores.

Streamline content creation and service publication

Administrators often use the default registered server connection in ArcGIS GeoEvent Manager to publish new feature services. Once federated, the default server connection in GeoEvent Manager switches from an ArcGIS Server connection to an ArcGIS Enterprise connection. With the registered server connection now addressing the Enterprise portal, you can use the managed geodatabase available with the Enterprise portal's hosting server.

Some system administrators may prefer that all published feature services be cataloged by a single ArcGIS REST Services Directory on the hosting server to streamline database maintenance activities and service discovery. Other administrators may prefer traditional map and feature services (those that do not contain real-time data) be maintained separately from feature services whose data is being updated in real time.

In the latter case, an administrator would register a traditional relational database with the ArcGIS Server they have licensed to run GeoEvent Server. Feature services associated with real-time data and workflows could then be published to the local server rather than to an Enterprise portal's hosting server. The ArcGIS Server, in this case, would not be federated with an Enterprise portal and GeoEvent Server administrators would use the default connection to access services on the local server. A separate server connection, to the ArcGIS Enterprise portal's hosting server, would be used to access services and content items hosted by the Enterprise portal.

Use stream services

When publishing a stream service in ArcGIS GeoEvent Manager, the registered server connection should be an ArcGIS Server connection to an ArcGIS Server that is licensed to run ArcGIS GeoEvent Server. When federated, this is not the case, as the GeoEvent Server default server connection points to an Enterprise portal.

While it is possible to select a server connection that addresses an Enterprise portal and make a request to publish a stream service, GeoEvent Server has to determine that the selected server cannot be used to publish the requested type of service and handle the error condition by reflecting the service publication request back on the requestor. Typically, in this case, the stream service is published to the local or real-time server rather than the Enterprise portal's hosting server without requiring any attention or action from the user. This can be a source of confusion, however, when it is not fully understood why services are being published to one server rather than another. Client applications expecting to discover services in the Enterprise portal hosting server's REST Services Directory will not find stream services in the hosting server's catalog. External clients may have trouble discovering stream services and subscribing to a stream service's WebSocket to receive feature records being broadcast.

Considering the store latest and related features capabilities of a stream service, some system administrators may prefer to maintain all feature services referenced by a stream service on the local or real-time server rather than publishing these related services on the Enterprise portal's hosting server. In some deployments, it may be just as easy to not federate, allow the default server connection to point to the local server, and use this connection to publish both stream services and feature services referenced by those stream services.

For more information on stream services, see Stream services.

Custom security configurations

When a system architecture integrates certain security elements at either the client or web tier, normal client/server requests sent between server machines can be rerouted when an ArcGIS Server is federated with an Enterprise portal. Requests a client sends to an ArcGIS Server running on one machine might be routed through Portal for ArcGIS running on another machine. The authentication needed prior to honoring the request might be lost or not handled as expected by a security element external to ArcGIS Enterprise.

When federating conflicts with a specific security configuration, it may be easier to not federate than rework a system architecture to accommodate the deployment of ArcGIS Enterprise.