If you are an Independent Software Vendor (ISV) that is developing applications for the education sector, you may have started your identity journey by owning the authentication experience for your end users in each application separately. This means that, in essence, you may have unknowingly created identity silos, whereby each application in your application portfolio developed and maintained its own authentication mechanism. Unfortunately, this approach doesn’t scale well. As a consequence, every application had to build its own UI and logic for end user sign-up, sign-in, password reset, and so forth.
Yet, that’s only half of the problem. As you onboard more customers, you begin to receive customer requests to allow their end users to be able to use their own existing credentials to access your applications. In fact, for some customers, that’s a hard compliance requirement and they may not do any business with your company unless you enable such an integration.
In the education sector, end users could be students, teachers, staff, and school district administrators, and the customer is usually either a school district in a given geographical area comprising of schools (such as K-12) or a post-secondary/higher-educational institution, such as a college or university.
Here are some of the most common identity providers (IdPs) that your education customers will be leveraging (in no particular order):
- Microsoft Entra ID (for example, using Microsoft 365 Education)
- Google Cloud Identity (for example, using Google Workspace for Education)
- Clever
- ClassLink
- RapidIdentity
It can certainly feel a bit overwhelming. How can you achieve single sign-on (SSO) with all these identity providers?
The following diagram shows what should be your desired target state high-level architecture for your solution:
As you can see from the diagram above, there are a few fundamental architectural decisions that should be driving your design. You need a customer identity and access management (CIAM) product, and there are plenty of these on the market, such as Microsoft Entra External ID, Auth0 by Okta, Transmit Security, and many others. The CIAM service sits at the heart of the solution.
The diagram clearly delineates the ISV infrastructure from the customer infrastructure. As an ISV, your responsibility is for your education applications and their integration with your CIAM service. Your CIAM service, in turn, will need to integrate with various IdPs that are part of your customers’ identity infrastructure, and so those IdPs are outside of your direct control.
You need to integrate each of your business/education applications with the CIAM service. Therefore, you will need to avoid performing a point-to-point integration between each application and each IdP. As a result, the design looks more like a hub and spoke architecture where the CIAM service represents the central hub with which all integrations are made. Likewise, each IdP should be integrated only once with the CIAM hub, and not with each individual application.
The major advantage of this architectural approach is that, as an ISV, you can work in parallel on both the left side (i.e. apps) and the right side (i.e. IdPs). Each application doesn’t need to know how the end user will sign in, because the CIAM service abstracts that away from the application. Likewise, each IdP only needs to integrate once with your CIAM service, and not with each individual application in your application portfolio. The architecture scales incredibly well as you add both more applications to your app portfolio and supported IdPs.
Of course, this is a desired target state architecture, and it does take a lot of effort to get there, but the advantage of this approach is that adding a new application integration with your CIAM service enables an end user to authenticate with your application via any of the IdPs that you have configured, and likewise, when you add another IdP integration to your list of supported IdPs, that will immediately benefit all applications in your application portfolio.
The CIAM service acts as a critical layer of abstraction and enables your business to quickly onboard new customers without having to reinvent the wheel every time a new application is added to your portfolio, or a customer asks for their particular IdP to be allowed to access your applications. As an added benefit to this approach, a single user will have a single account (and a single identifier) in your CIAM service and will be able to leverage that same account (i.e. same credentials) to access any of your applications.
From a business perspective, you will be able to achieve a holistic customer 360 degree view to understand access patterns for a given customer across all your applications, which would help your sales, marketing, and support teams, to be able to better support, up-sell or cross-sell to your education customers. Finally, this architecture will enable you to meet your customers’ security and compliance requirements, such as allowing your customers to leverage their existing multi-factor authentication (MFA) methods to gain access to your applications, and would further enable the customer to be able to define their own granular adaptive access policies that govern and control access to your applications.
If you are an ISV that is facing a similar challenge, feel free to reach out. I would be happy to help!