For a while we have recommended that the best approach for managing ArcGIS Online or ArcGIS Enterprise portals, including named users, entitlements, Esri Access, credits, etc., is to enable enterprise logins, commonly referred to as Single Sign On (SSO). So far, the only supported configuration for enterprise logins was using one identity provider (IDP), Shibboleth and Active Directory Federation Services being some of the common ones in academia.
As of the latest June 2018 release of ArcGIS Online (and the pending ArcGIS Enterprise 10.6.1 release in July), we now support enabling enterprise logins via a federation of identity providers. Identity federation allow users belonging to an existing inter-organizational federation, such as InCommon (United States), SWITCHaai (Switzerland), DFNaai (Germany), and others, to sign in with credentials supported by that federation. Each member organization continues to use their own IDP, but configures an SP (i.e. ArcGIS) to work exclusively within the federation. This is a request we’ve received by quite a few institutions and wanted to document some of the functionality and cases where it may be beneficial.
NOTE: ArcGIS is not joining the InCommon, Switch or DFN federations as a member. Hence, Esri will not be listed as an SP entity. Rather, ArcGIS Online or ArcGIS Enterprise portals will need to be added as a new SP to the federation. This will enable users to share and access their web resources within the federation, and have a seamless login experience. The following SWITCHaai documentation provides an easy to understand explanation and graphic.
- Cases where it would be beneficial:
- Requirement imposed by institution’s IT/Central Services – many institutions who are InCommon participants have been able to implement enterprise logins configured with one identity provider (IDP), however, some institutions have their own requirements that mandate support for identity federation. With identity federation supported in ArcGIS, now these institutions who have such requirement could proceed with enabling enterprise logins.
- Multiple campuses using multiple identity providers (IDP) – for example, three campuses of the same institution using three different Shibboleth instances to provide identification – in these instances, institutions will use identity federation to integrate with their three local Shibboleth installations. This will be an example of identity federation, which is not related to InCommon, SWITCHaai, DNFaai, or other inter-organizational federations.
- Potential benefits for users who wish to enable collaboration across and between different educational institutions - for example, if this capability did not exist, and a student/faculty/staff from University X wanted to access resources hosted by University Y, they would need an account from university Y to login to the portal. Therefore, to access resources spread across different, un-federated universities, one would need different login accounts, which complicates both user login experience and user management. Having identity federation will simplify this and allows for a single enterprise ID to be used (as long as the institutions belong to the same federation).
- Learning Tools Interoperability (LTI) compatibility requirements – LTI being a protocol for various services and service providers to integrate with Learning Management Systems (LMS) – some entities have this requirement to connect LMS with external service tools (i.e. ArcGIS). Since ArcGIS technology provides a teaching and learning environment in education, this new identity federation capability could fulfil such requirements to integrate ArcGIS technology with LMS platforms.
- Identity federation setup and user experience:
- An institution must be a member of a federation to use this new feature. When administrators and IT staff configure enterprise logins using a federation of identity providers, there are a number of parameters needed, including URL of the federation (Federation Discovery Service URL), Metadata Aggregate URL, and Certificate to validate the aggregate metadata.
- When identity federation is configured, the same option applies as when using a single IDP – users will be able to join automatically or by invitation. When multiple institutions are members of the federation, it may be recommended to use the “Upon invitation from an administrator” option. This means that users from a federation must be explicitly invited, i.e. in the ArcGIS Online or ArcGIS Enterprise portal settings, an administrator would go to Invite Members, and use the option “Invite members to join using their enterprise logins”. Then users would be able to have the same user login experience, using their respective institution’s enterprise credentials. Sharing of content is protected by the existing ArcGIS security model and groups are leveraged to restrict access. Note, SAML-based group membership is not yet supported with identity federation.
- Once the ArcGIS Online organization is registered as a member of the federation, the login experience is the same on the initial login page (when the user chooses either to login using an enterprise account or ArcGIS account). If identity federation is configured, the organization is a member of a federation of multiple members, what needs to happen is the federation needs to identify the home organization, i.e. where you are from, and a user will be prompted to a centralized Discovery Service Page, on which they will be asked which university/entity they belong to.
Further feedback is welcome!