Federation is definitely a hot topic these days, with NSTIC attempting
to create an identity ecosystem, InCommon continuing to build its
federation of service providers, and state-level initiatives gearing up
(some are already active) to provide federated identity services to
4-year schools, community colleges, K-12, and every entity in between.
But I’ve found that many schools and institutions are not prepared to
commit to the rigorous list of technical requirements to enter into such
federations. This is primarily because of a lack talent, lack of
budget to obtain the talent, and resource utilization constraints.There are other potential roadblocks facing institutions that choose to walk the federated identity path. The standard model of requiring a unique Shibboleth installation (which by default would provide a localized IdP login screen including a custom URL for the login screen) is simply not appropriate for smaller colleges and universities that can’t afford to hire more technical talent. It’s also not feasible for K-12 as it would require technical resources to be located at each school.
A virtual identity provider (vIdP) model is the best option for institutions that don’t currently have any SSO capabilities as it eliminates 90% of the technical federation hurdles placed on entities. This model will resonate well with smaller colleges and universities, K-12, and any other entity that lacks the key components to enter the secure world of federated identity management. The only difference between a virtual IdP and a localized one is you will spend half the money and spend 90% less time to deploy a virtual IdP. There is no reason why entities falling behind in the federated world should not consider deploying a virtualized IdP.
The virtual IdP model provides economies of scale to reduce costs by securely sharing resources among multiple institutions. In contrast to local IdPs that require one or more instances 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 virtual IdP model is far simpler for institutions. A virtual 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 of distinct IdPs per entity. It is also important to note that the Shibboleth software does not reside on campus, thereby eliminating the need for each individual campus to have any [technical] federation knowledge at all. Institutions that lack talent, time or both are no longer locked out of the federated world in the virtual model. In fact, if success looks like massive uptake of federation, then using virtual IdPs is the best chance for success.
However, every new technology has its critics: Some people believe that the federation identity provider (IdP) should always be local (i.e., on campus) as opposed to leveraging the cloud for IdP services. Maybe this is because some in the industry are not yet comfortable with a virtual approach out of a lack of understanding regarding security and risk for a virtual versus an on-campus IdP. I’ll address their concerns one by one.
Some critics claim that a vIdP is not secure, but security issues for a virtual IdP are no different than for a localized IdP deployment. The same underlying protocol, SAML, is used; therefore the same security mechanisms are in place, the same configuration is in place, the same platforms are leveraged, the same application set is accessible. And service providers hosting vIdPs are often more secure and provide higher availability than many institutions can achieve locally.
Some critics argue that a virtualized IdP is never feasible because they believe there is a lack of branding. But, virtualized IdPs can be branded the same as local IdPs, and the user experience for the virtualized login process is just the same as the fully-branded and customized local IdP model.
Some federations do not want to allow virtual IdPs into their trust models, presumably because they don’t believe that virtual IdPs are as trustworthy, or possibly the federations don’t understand the implications that vIdPs have (or don’t have) on their business trust models. In reality virtual IdPs are often more trustworthy from a technical perspective than a local IdP model: The data center is more secure, access to the data is more secure, I could go on. And from a business perspective, although the technical aspects of a vIdP are outsourced, business agreements are not outsourced, and the business trust model remains unchanged and between the same parties.
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 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 and are essentially cutting off their noses to spite their faces. Maybe their real issue is that reporting actual IdP installations looks better to some people than adding the same number of institutions on virtualized IdPs? Maybe their issue is simply attempting to undermine commercial solutions in the name of their own pet open source initiatives?
Truth be told, virtual identity providers scale much better than localized IdP / federated infrastructures. Virtual IdPs are just as secure and trustworthy, and are more cost effective for the institution tasked with federating their users to access service providers.
My advice to you would be not to discount a virtualized approach. A virtual IdP can be up and running quickly, it can be configured easily, and your users will be federated in a fraction of the time it takes to stand up your own infrastructure.
No comments:
Post a Comment