Why Single Sign On for academia (SAML logins)

6898
5
10-17-2017 11:15 AM
GeriMiller
Esri Regular Contributor
6 5 6,898

*Updated 2023

For a while we have recommended that the best approach for managing ArcGIS Online is SAML logins (previously known as enterprise logins), commonly referred to as Single Sign On (SSO). SSO is a capability supported by many vendors, which has been broadly implemented across organizations, including in higher education, to enable a user to access multiple systems with a single username and password.

With the upcoming retirement of ArcGIS Desktop,  the ArcGIS named user model will be the only method to license ArcGIS. Single Use and Concurrent Use methods of licensing ArcGIS Pro will be deprecated. Hence, it is crucial that organizations implement SAML logins for efficient access to all ArcGIS apps, including ArcGIS Pro.

The information below will be useful for those who are not familiar with or have not yet implemented SAML logins.

SSO explained

  • SSO enables a user to use the same set of credentials for signing into multiple applications. This means that students, faculty, and staff can use the same credentials coming from their institution’s enterprise identity store to login to ArcGIS Online.
  • When configured to use SSO, ArcGIS relies on your institution's authentication and authorization mechanisms. When a new user accesses ArcGIS for the first time and they successfully authenticate and are authorized, an ArcGIS Online account is automatically created and linked to their institutional identity.
  • SSO can be set up for any of your ArcGIS Online organizations or ArcGIS Enterprise instances.

What are the benefits of SSO

  • Ease of access – one set of credentials will be used.
  • Simplified User management – this is HUGE for academia. Enabling SSO means that no additional account logins need to be created for ArcGIS Online. We don’t have to add students to the organization manually (or via script) and share credentials with them.
  • It eliminates inefficiencies associated with creating and managing multiple accounts, which takes time and thus is an incurred cost. Students and faculty have one account only, which makes it easy to save projects and build their geospatial portfolio.
  • When a student or faculty is no longer affiliated with the university, and has been removed from the institution's identity store, access is prevented automatically. They will no longer be able to login to ArcGIS Online.
  • Having SSO enabled could help facilitate easier tracking of ArcGIS Online usage across campus. Once you are using institutional identities, then you have a key to join information between ArcGIS Online and your authoritative campus systems. For example, you can collect information such as usage across degrees and programs, or take a username from ArcGIS Online and determine a user's role (student, faculty, staff) from another system, etc. An example is described here 

What you would still need to do (i.e., what tasks it does not eliminate)

  • Manage groups – a group for a course or project may still need to be created, and users added to it. SAML-based group membership functionality is available to help with this workflow.
  • Manage content when a student or faculty leaves the institution, if desired.  
  • Communication will still need to take place when offboarding users (graduating students, faculty leaving an institution), to ensure they are prepared before  they lose access to the institution’s organization. Check Messaging for ArcGIS Online users leaving the university.

Organizational challenges and solutions

  • Cost Savings – we have seen a handful of instances where a cost recovery policy precluded enabling of SSO.
    • Proposed solution: While organizational structures and approaches differ, we have recommended Central Funding for ArcGIS software (not support/services) in combination with adoption of SSO. That has worked well for many institutions. While such a change may impact budgets in different units in different ways, the overall result is lower total cost of ownership for the institution through efforts saved on managing ArcGIS. Please check Funding and Support Models for GIS and We only provide MS Excel for Business majors resources.
    • Collaboration with IT – we sometimes hear of a lack of collaboration with IT units as a barrier to SSO. In the majority of these instances, the initial communication with appropriate IT teams has not been made, or one attempt was made and not followed up on.
      • Proposed solution: SSO has become an industry standard with which campus IT organizations are now very familiar. Please reach out to the appropriate team(s) and place a request to use established methods for your institution. It is important that the initial communication with your IT team(s) be clear, complete, collaborative, and include a specific request to implement SSO to support ArcGIS. Be sure to follow-up at regular intervals to ensure the implementation goals are met. Using SSO for ArcGIS, in collaboration with the appropriate campus IT resources, requires little ongoing effort to maintain, while you can realize enormous savings in effort spent managing accounts.
    • Technology issues – they rarely appear though we do hear of them occasionally.
      • Proposed solution: Please reach out and work with Esri Technical Support. They are there to help. In addition, please reach out to highered@esri.com for additional support and recommendations. Because the SSO approach is based on industry standards, issues are rare, however, when they do occur, working with Esri Support to resolve your issue will also benefit others in the educational community with similar implementations.

Bottom Line - How do we do it

    • Work with your IT department and refer to the documentation – these are industry standards, and IT staff will be aware of them.
    • Attached is a template letter to College/University IT staff that could be used to request SSO.
    • Esri Technical Support is there to help if any issues arise.

 Further feedback is welcome!

5 Comments
StaceMaples
Occasional Contributor III

This has been a useful post for working with our IT partners to successfully implement SSO for AGO. Now that it works, it occurs to me that a boilerplate statement template to users about SSO and it's implications for new AND existing users would also be fantastically useful. Something that helps explain some of the dynamics you highlight above, but for users. I can imagine the following questions will be coming soon after our announcement:

"I've been using an Esri GlobalID for logging into AGO. How do I migrate my content to the new username?"

"I've recently left Stanford and I'm no longer able to access my content on AGO! How can I recover it?"

And so on...

Stace

GeriMiller
Esri Regular Contributor

Great questions, Stace. To have a such boilerplate statement to users, one would need to identify how the transition from arcgis-only, to enterprise accounts, will take place. We encourage transparently migrating the accounts for users, and doing it all-at-once. All the user needs to know, from their perspective, is that they now need to use their university credentials after some announced downtime. Other approaches are possible, but will result in extra work, and possibly confused users. 

Below are a few ideas for implementation strategy:

  •      Use the ArcGIS API for Python to facilitate this transition and transfer content from a source user (arcgis-only) to a target user (enterprise user) Please take a look at the following sample that does exactly that, and was specifically written with this workflow in mind. An added benefit of using this approach is that group membership gets maintained as well. 
  •       Communicate with users - notify users ahead of time of impending transition to Enterprise logins, and set a timeframe when ArcGIS Online will be unavailable to them. Consider noting the benefits they will be gaining. 
  •       Remind users of new login workflow - now they will be using their enterprise credentials. 
  •       You would need to create mapping between arcgis-only and enterprise accounts. 

What the above approach/script would do:

  •      For each arcgis-only, non-admin account, create an enterprise account.
  •      Reassign group ownership.
  •      Reassign content ownership.
  •      Disable arcgis-only account - deleting accounts is more complex, as you have to revise entitlements and disable Esri Access.

If you are just getting started, and not ready to enable enterprise logins, yet, consider the following to help with a smoother migration down the road. 

  •      Create arcgis-only usernames that match enterprise usernames (do not add the org suffix, such as gmiller__myuniversity) - currently ArcGIS Online will not protect the namespace for an enterprise account. 
  •      The above makes it easier to keep track and look up users in other systems, such as LMS/SIS, campus directory, etc. 

We welcome any further thoughts and if anyone has been through this process before, please share any experiences and approaches.

curtvprice
MVP Esteemed Contributor

Create arcgis-only usernames that match enterprise usernames (do not add the org suffix, such as gmiller__myuniversity) - currently ArcGIS Online

That's interesting, we implemented SSO and the usernames the system creates have the suffix: <email_address>_sdmines.

GeriMiller
Esri Regular Contributor

That is correct, once you enable enterprise logins, you will get the suffix, i.e. cprice_sdmines.

What the above suggested is that if you are creating an arcgis-only account, before you enable enterprise logins, you do not add the suffix. If you do, this could create a namespace conflict, once you implement enterprise logins, two accounts cannot be named the same and you would have to address that. 

MatthewStull1
Occasional Contributor II

Hi, can you confirm that what you said here:

As an administrator, it would be easy to find disabled accounts, determine what would be done with their content, then remove the student account from the portal. 

Has to be done manually?  I am wondering if there is an automated way to remove Enterprise/Single Sign-On users?