The SSO Shift: Navigating Cloud Choices in Higher Ed IAM

Kellen:
Many challenges stem from the decentralized nature of higher education institutions: departments, schools, and research centers with their own IT systems and identity silos lead to multiple layers of required integrations with the cloud system. Trying to create and maintain these links while preserving autonomy can be difficult. Coupled with the fact that many institutions also have a complex hodge-podge of custom and legacy systems means that there aren’t necessarily clear-cut paths to the cloud.

Tommy:
Our primary challenge is in dealing with products that were not designed with the complex nature of higher education institutions in mind. For example, the concept that an individual can have multiple university relationships is not a native concept for some products. Instead, there is a general assumption that when an individual loses an affiliation with the institution (e.g. they’re fired), their accounts and permissions will be eliminated from the product. In higher education that user could have multiple affiliations, and any one of those could require them to continue to have an account in that product.

As we transition to cloud-based products, our IT teams will be strained to learn and adapt to new products, technologies, and processes while still supporting existing ones. This strain will continue while we’re in a hybrid state, which is likely to be for a prolonged period of time.
Persuading our user community to move away from older familiar technologies, like mapped network shares for storage, to the newer cloud equivalent is challenging. Change is always challenging, especially as the transition can be disruptive to important activities

Kellen:
One of our primary goals is to provide a better user experience. With our current environment, SSO isn’t so much “single sign-on” as it is “same sign-on”, where the same credential work for either our on-premises Shibboleth Identity Provider (IDP) or our cloud IDP (Microsoft Entra ID), each of which has >500 application integrations. Unifying the experience is not only better from the experience perspective but also from a security and compliance perspective. Scalability of the solution and cost efficiency are further reasons for our examination of how we can better leverage the Microsoft Entra offerings.

Tommy:
One driver is to get well ahead of product deprecations. A specific example is that Microsoft is clearly transitioning away from Active Directory. No significant developments have been made to Active Directory since Windows Server 2016. While our Active Directory domain may be around for the next 20 years or more, we need a transition plan that will allow us to move away from it at our own pace and schedule rather than on Microsoft’s schedule at some unknown point in the future. For our institution we are formulating a plan to transition from Active Directory to Entra ID as our directory service. At the moment we’re in a hybrid state where we use both concurrently. That journey began in 2014 when we created our Microsoft Azure tenant, and began to synchronize most objects from Active Directory to Entra ID. Staying in hybrid mode poses several challenges so we must plan our transition out of it.

Another motivation is the desire to take advantage of new technologies available in the cloud products. Since Microsoft’s focus has moved to its cloud products, the most interesting technology developments are occurring there. We believe that new cloud-based “passwordless” authentication technologies such as Windows Hello for Business will represent a significant improvement in user experience as well as security. This introduces the need for a slew of prerequisite cloud-based products including Entra-join, Autopilot, Intune, and Platform SSO.

Kellen: 
We’re in the early stages of our process and still learning, but one crucial lesson is to prioritize requirements gathering. Your project, or likely a series of projects, must carefully balance security, compliance, and operational needs. Deploying a solution that doesn’t support complex identity lifecycles or integrate seamlessly with legacy systems can lead to frustrated users, security issues, and costly rework in the future.

Tommy:
Transition gradually wherever possible. Start slow, make mistakes early, get early adopters from every IT team and take their feedback very seriously.

Kellen:
Plan carefully, secure buy-in from stakeholders early, and seek advice from peer institutions through forums like Internet2 conferences, working groups, and training.

Tommy:
Always learn from other people’s mistakes first and then go make your own mistakes. Learn, improve, and then share!