Identity Management

Ready The Pipes

Experts say the future of federated identity management lies in the integration of academic and consumer apps—and now is the time to get the infrastructure in place for convergence

• By Katherine Grayson
• 03/01/10

IF THERE’S ANYONE IN THE ACADEMIC IT ARENA taking seriously the possibility that campus identity management (IdM) may one day meld with consumer apps, it’s Nate Klingenstein, one of the founding members of the Shibboleth Project (the open source project providing architecture and policy structures for managing single sign-on access to resources).

Such convergence means students and faculty accessing next-gen applications with single sign-on—which, now more than ever, has become a user expectation. “I see a world where a student accesses a social application using his Facebook identity, and that ID is connected to the university, using federated identity as ‘plumbing,’” Klingenstein explains. “That way, the student can use the social app as a recognized member of the university, and, in the process, provide the institution with information about his progress in his coursework.”

Yet, he stresses, a vital question is: Which entities will have control over users’ personal data (otherwise known as attributes or credentials), and how much information is the campus willing to let other entities—possibly commercial vendors—share? (See “Sharing Data With Social Apps” on page 26.)

Undoubtedly, that question is one of the snags holding up campus/consumer federated IdM convergence. Meanwhile, though, students are moving quickly to access myriad resources—social or otherwise—in their quest to share information with peers, and they don’t like grappling with dozens of IDs and passwords. What’s more, it’s often impossible to separate their access needs into personal, social, or academic categories because the lines are frequently blurred, even within a single communication. For instance, new tools such as Google Wave (which enables real-time communication and collaboration via instant message, document sharing, and other services) have the potential to bridge academic and consumer worlds—making it that much more important for campus IT shops to prepare for convergence.

Convergence Ahead

In fact, a recent Chronicle of Higher Education blog post (www.chronicle.com/ blogPost/could-google-wave-replacec/ 8354) posited that Google Wave could replace the traditional course management system (CMS). While that’s not likely to happen anytime soon, now is the time for campuses to get the identity management infrastructure in place for the converged future that Klingenstein considers inevitable. The key link between the university and the social or consumer application is a strong campus federated IdM system, he stresses. “Those attribute pipes need to be in place on campuses,” he says. “If we don’t build the pipes, we face two unsavory alternatives:

“One, the new tools [that kids want to use] can’t be available in the campus learning environment.” (That is, because the campus will not allow its constituents’ personal data to end up in the hands of third-party services.)

“Or, two, the quality of student information and the ability of the university to manage things like grades and the student base will erode.” (This, if the campus does permit the integration of third-party applications, yet surrenders personal data control because it lacks its own robust capability to manage that information.)

Simply put, says Klingenstein, “If we don’t build the pipes, we end up with a bad learning environment or bad ID management—one or the other.”

UNC: ‘Future Proofed’

One institution with strong tech leadership in identity management is the University of North Carolina system. From his Chapel Hill base, Director of Online Services Steven Hopper explains, “Authentication is the baseline for any application anyone ever writes. You always need to validate that the individual user is who he says he is.”

But it wasn’t long ago that the UNC IT folks were facing the same authentication challenge over and over again, each time a constituent school started using a new application or vendor. “Every vendor was a brand-new situation, solved again and again, and all the solutions were different,” recalls Hopper. All of the customization time was astoundingly cost- and labor-intensive, he admits. “We realized that if we standardized on the [identity management] technology, we would have all the pipes built.”

He goes on to explain that ever since UNC’s attribute pipes were constructed on the Shibboleth SAML2 (security and assertion markup language) standardized platform, there’s been no need to reinvent the wheel and rewrite code for every new third-party application that comes along. “The pipes are in place, and we just fill them with water. Adding on new services is now simply incremental, not from the ground up each and every time.”

So, what about the convergence with consumer Web 2.0 apps? “Moving [our identity management] out to Google and the rest is now easy,” claims Hopper. “All of those providers are using the exact same technology, and the power of that makes everything we do, going forward, much more standard and much more supportable.” He notes that many of the UNC system campuses have chosen the Microsoft Windows Live higher ed services, plus Google Mail and Apps. In those situations, he maintains, academic and consumer federated IdM convergence simply makes sense.

“Our UNC vision is to interoperate among our 16 constituent schools and our third-party providers, government applications, and library resources. And it all boils down to having Shibboleth SAML2,” says Hopper.

For the layperson, he explains that federated IdM via SAML2 is light years beyond LDAP (lightweight directory access protocol), the previously existing means for accessing information directories such as organizations, individuals, phone numbers, and addresses. For universities, he points out, there have been real problems maintaining ownership of credentials via LDAP.

Before SAML2, “If a campus wanted to implement LDAP, it would have to open its firewalls to each and every third-party vendor, creating major holes in those firewalls. When a student supplied credentials, the third-party service provider would read those attributes and pass them on.” The danger, says Hopper, is that no one would have any way of knowing what that provider would do with those attributes. “There wasn’t even control to audit the credentials and see what was going on. Sure, you could set up auditing and security measures, but that was very cumbersome.”

Now, standardized on Shibboleth SAML2, the setup is just the opposite, he says. “Instead of the user giving his credentials to, say, Google, he gives his credentials to the campus that issued them—there’s no third-party provider handling those attributes.” (For more info on how Shibboleth works, see “Mutual Trust,” CT February 2008; www.campustechnology.com/articles/ 2008/02/mutual-trust.aspx.)

Hopper is quick to confess that cost savings and an urgent need to streamline a spinning-out-of-control authenticationwriting process were behind UNC’s move to federated IdM. The man-hours saved for development and solution customization have been “incalculable,” he confides, and have greatly outweighed the Shibboleth software (and any associated hardware) expenditure.

Yet there was an equally important motivation: “Sure, we did this to make things easier and save money,” Hopper says, “but we also did it to ‘futureproof’ ourselves. Federated IdM sets us up to quickly respond to new offerings in the marketplace, and even gain a competitive edge. Mostly, we’re putting ourselves in the best possible strategic position. Whatever comes along, we can meet it in a more efficient way.”

UNC has made a strong commitment to keeping the federated IdM infrastructure going, notes Hopper: “We’re now using federated IdM as part of our RFP [request for proposal] process with vendors.” This means that when UNC’s larger campuses make major application buys, other constituent schools will be able to make use of those apps via the single sign-on capability that runs across all 16 campuses in the UNC system. All in all, UNC’s Shibboleth-enabled federated IdM system has been so successful that the UNC systemwide security committee is formally recommending that going forward, all third-party apps be required to be Shibboleth-compliant.

Hopper offers the following advice to other campus tech leaders grappling with their own federated IdM initiatives (or considering such a prospect):

Get over the hump to do something. Most schools won’t move full-throttle into federated IdM until a champion is found and internal marketing takes off. Find someone who understands the technology but can handle the political piece, as well. Then put together a solid strategic plan and nail down the right deployment approach.

Standardize on the technology to authenticate. Don’t create authentication over and over again for every new app or for every new constituent-school need. Use open-standards federated IdM technology to solve that challenge once, and every new challenge will be incremental.

Set policy before releasing credentials, and make sure you audit it. For example, says Hopper, “As part of our policy framework, every user’s attributes are passed through the user’s web browser. If a student wants to access a third-party resource and that resource requests a particular attribute, because of the user’s web browser setup we can send him a message: allow or disallow? That way, the student has the control over his own privacy.”

Find the critical application that has to happen—then use it as a catalyst to launch the federated IdM initiative. “My first weeks on the job, the CIO discussed federated IdM but nothing happened for four years; it was an abstraction that no one saw as urgent.” Then, says Hopper, an inter-institutional registration system came along (enabling students to take courses at other UNC campuses) and “we had to verify that UNC students were who they said they were. This finally gave me the leverage to say, ‘We’re going to do it!’”

USC: It’s All About Trust

At the University of Southern California, converged federated identity management is a strategic goal—one that’s being approached with caution. Identity Services Architect Brendan Bellina describes the institution’s efforts to move its seven-year-old identity and access management (IAM) system toward federated IdM: “Our IAM works toward the vision of a single master identity record for each person.”

Many departments are involved in the move to federated IdM, he says, and each year the number of new services offered to students, faculty, and staff—some internal, some external, and all requiring robust identity management—has exceeded that of the prior year. USC has been at the forefront of schools enriching their technology offerings with external services such as iTunes U and Google Apps, and as a result federated IdM can be “daunting,” Bellina admits.

“In light of the growing use of consumer and user-centric IDs, one challenge will be determining what roles these [external] identities that are presented to the university will play,” he says.

“In today’s USC environment,” he explains, “members of the community are assigned identifiers that are scoped to the institution. A student has a USC-scoped e-mail address, for example. That address is assigned by the university and can be trusted by faculty, staff, and other students. There are ways to ascertain the validity of such addresses and ways to track their use, and these identifiers often are how students are known within the electronic services they use.” In contrast, consumer e-mail addresses, commonly used as identifiers to access external applications, lack that institutional validation. “Though the use of consumer identities to access valuable applications can certainly enrich the learning process, there is the issue of trust,” Bellina points out. Any system mistrust of identity would block access to the needed app, and “that would lead to restrictions in services, and adversely affect the academic experience,” he suggests.

Still, “Students coming into the universities today use their engagement in online communities as support systems, knowledge bases, and sounding boards,” he acknowledges, conceding the new learning impact of what once were seen as strictly social or consumer applications. “At USC we’re investigating how communities like these can be leveraged in the educational setting. We’ve looked at wikis, blogs, and virtual reality engines.” And Bellina’s team is carefully assessing the identity management issues inherent in their use across the university. Sharing the management of personal student data with third-party providers presents a real issue for USC.

“Before any institution is comfortable allowing established social networks to extend into its space,” Bellina asserts, “each has to be investigated as an isolated instance. If a trust model can be established between the consumer identity provider and a university such that sensitive information no longer needs to be shared in order to establish identity, then that will be a win for everyone.” However, he says, there will remain many reasons why sensitive information must be available to a university, and many reasons why someone—a researcher, for instance—won’t want to share that information with a consumer identity provider.

Bellina, for one, is a staunch proponent of a strong campus IAM system—with or without federation. Yet he also sees the advantages of federated identity management, with or without allowing commercial identities to access the institution’s services. But, “Transitioning institutions away from [their own identity records] to reliance upon commercial identity sources is going to be disruptive to some degree,” he maintains, adding, “It’s reasonable that an institution might even fear long-lasting impacts of doing so.”

Bellina suggests that schools hesitant to commit to campus/consumer federated IdM—or schools and systems looking for help federating identity management across an entire system or campus—consider jump-starting such initiatives with a strategic “policy-plus-federations” plan.

“For schools considering a federated identity management initiative, the use of federations such as InCommon to provide services has proven to be very beneficial. And I strongly recommend establishing an identity and access management governance function. This will help to ensure that as you move forward, the technology implementation will not determine policy, and that the appropriate policymakers at the institution are fully engaged. Make this the foundation upon which you build, and—whether you eventually move toward the convergence of campus and consumer identity management or not— you will be more likely to succeed.”