Why Higher Education Institutions Need Cloud-Based Identity Providers

By Dan Dagnall, Chief Technology Strategist for Fischer International Identity

Federation is definitely a hot topic these days, with NSTIC attempting to create an identity ecosystem, InCommon continuing to build its service-providerfederation, and state-level initiatives gearing up (some are already operational) to provide federated identity services to 4-year schools, community colleges, K-12, and every entity in between. But I’ve found that many institutions and schools are not prepared to commit to the rigorous list of technical requirements to enter into such federations. This is primarily because of a lack of talent, lack of budget, and resource utilization constraints.

Institutions that choose the federated identity path faceother potential roadblocks.The standard model requires a unique Shibboleth installation (which by default,would provide a localized identity provider(IdP) login screen and a custom URL for the login screen)which is simply not appropriate for smaller colleges and universities that can ill afford to hire more technical talent. Localized IdPs are also not feasible for K-12 as they would require technical resources to be located at each school.

A Cloud-based identity provider (cIdP) model is the best option for institutions that don’t currently have any SSO capabilities as it eliminates 90% of the technical federation hurdles. As a result, this model should resonate well with smaller colleges and universities, K-12, and other entities lacking the key components to enter the secure world of federated identity management. The only real difference between a Cloud-based IdP and a localized one is you will typically spend half the money and 90% less time to deploy a Cloud-based IdP than a localized one. And I can find no reason why entities falling behind in the federated world shouldn’t consider deploying a Cloud-based IdP.

The Cloud-based IdP model reduces costs through economies of scale by securely sharing resources among multiple institutions. In contrast tolocal IdPs,which require at least one instance of Shibboleth software to be installed for each institution, each with its own set of metadata to be configured, and each of these with its own maintenance by technical specialists, all of which add to costs, the Cloud-based IdP model is a far simpler approach. EachCloud-based IdP needs only a single installation of the Shibboleth software and a single set of metadata to accommodate multiple institutions, which dramatically reduces the on-going support compared to supportingat leastone IdP per entity. It is also important to note that because the Shibboleth software does not reside on campus, there is no need for each individual campus to have any technical federation knowledge. Therefore, the Cloud-based model unlocks the door to the federated world for institutions that lack talent, time, money or all three. In fact, ifwe judge success by a massive uptake of federation, then using Cloud-based IdPs provides the best chance for success.

However, every new technology has its critics, and Cloud-based federation is no exception:Some people believe that the federation identity provider(IdP) should always be local (i.e., on-campus) and therefore, unable to leverage the Cloud for IdP services. Perhaps this is because some in the industry are not yet comfortable with a Cloud-basedapproach, possibly out of a lack of understanding regarding security and risk for a Cloud-based versus an on-campus IdP.I’ll address their concerns in turn.

Some criticsassert that a cIdP is not secure, but security issues for a Cloud-based IdP are no different than for a localized IdP deployment. In both cases, SAMLis the underlying protocol, with the same security mechanisms in place, the same configuration in place, the same platforms are leveraged, and the same application set is accessible. Also, service providers hosting cIdPs are often more secure and frequently provide higher availability than many institutions can achieve locally.

Some critics argue that a Cloud-based IdP is never feasible because they believe there is a lack of capabilities for institutionalbranding. But, Cloud-based IdPs have the same branding options as local IdPs,and the user experience for the Cloud-based login process is identical toa fully-branded and customized local IdP deployment.

Some federationstry to disallow Cloud-based IdPs into their trust models, presumably because they don’t believe that Cloud-based IdPs are as trustworthy, or possibly the federation managementlacks understanding of the implications that cIdPs have (or don’t have) on their businesstrust models. From a technical perspective,Cloud-based IdPs are often more trustworthythan local IdPs:Typically,the data center is more secure, access to the data is more secure, and so on.From a business perspective, although the technical aspects of a cIdP areoutsourced, the business trust model remains unchanged and between the same parties, as business agreements are not outsourced.

Some critics advocate for localized IdPs while at the same time supporting internal deployments of dirSynch or Google’s synch process to provide Cloud-based email services to their user populations, which, by the way, stores user data in the Cloud. So if the issue is related to where the data is stored, then their logic is flawed as they are advocating both sides of the same coin. It’s like they’re cutting off their noses to spite their faces.Maybe their real issue is with reporting, as reporting actual IdP installations might look better to some people than reporting the same number of institutions on Cloud-based IdPs? Or maybe some people are simply attempting to undermine commercial solutions in attempt to supporttheir own pet open-source initiatives?

All things considered, Cloud-based identity providers scale much better than localized IdP / federated infrastructures. Cloud-based IdPs are just as secure and trustworthy (often more so), and are more cost effective for institutions tasked with federating their users to access service providers. My advice: don’t discount a Cloud-based approach, as aCloud-based IdP can quickly be operational, can be configured easily, and can federate your users in a fraction of the time it takes to deploy your own infrastructure.