Internet2: Extending Identity and Access Around the Globe with InCommon
A Q&A with Ann West and Kevin Morooney
During its 25th anniversary year we've been looking back at the evolution of Internet2, highlighting its technological advancements and the vibrant community at its heart. Today, we're talking with two Internet2 executives about InCommon, a key component of Internet2, both in its organizational functions and as technological infrastructure.
"After the determination was made to build this great network, one of the immediate and most important challenges was to work on ways to make services available, at scale, in a secure and privacy-preserving way." —Ann West
Mary Grush: When did InCommon come about in the 25-year timeline of Internet2, and how did it emerge from the initial work of Internet2?
Ann West: Internet2 was founded in 1996, and after the determination was made to build this great network, one of the immediate and most important challenges was to work on ways to make services available, at scale, in a secure and privacy-preserving way.
In the early days, much of this foundational work came out of two efforts: the Internet2 Middleware Initiative, which first convened in 1998; and the Common Solutions Group, which represents about 30 organizations — mostly larger research institutions — that were looking further into the best ways to support collaboration over this far-reaching network.
Initial funding for that work was with an NSF grant [#9983218], a relatively small planning grant in 1999. From there, about $10 million in NSF grants over the next several years, as well as a Department of Commerce grant, funded the building of an interoperable identity and access management infrastructure that enables access across the U.S. for academic scholars and researchers. And that work received acceptance and was adopted globally over time.
Much of the early work of the Internet2 Middleware Initiative came out of some highly regarded thought leadership, including Ken Klingenstein, who was then at the University of Colorado-Boulder, and Bob Morgan, who was at the University of Washington.
Grush: So then InCommon has a rather long history, though not quite as long as Internet2?
Kevin Morooney: Correct. Work on InCommon itself, both as an organization and infrastructure, started in 1998/1999. About five years later, InCommon was stood up, and of course matured along with Internet2.
Grush: Today, how would you characterize InCommon? Why is it such a central piece of Internet2 and how is it perceived by the community?
Morooney: It is both a challenge and a delight to be part of the ecosystem that delivers on its promise in the numerous contexts of what InCommon means to many different people.
It is both a challenge and a delight to be part of the ecosystem that delivers on its promise in the numerous contexts of what InCommon means to many different people.
To some people, InCommon is a community. It's a community of people who care deeply about enabling collaboration — whether globally, nationally, or just within their own campus. They are passionate about enabling scholarship, which by its nature has required collaboration for thousands of years. Now that most scholarship has moved to digital environments, facilitating collaboration takes on new challenges, but it also affords really interesting opportunities as well. You can begin to pull together minds from all around the globe, leaders in their fields who can be brought together to address problems of real import to society at large.
So, it's a community of people who care about all of that and come together to determine and define common problems, identify common opportunities, and try to seize upon those opportunities with organizations like Internet2.
InCommon is also infrastructure. It's infrastructure that universities, research organizations, and commercial service providers can connect to, to be part of and enable the kind of collaboration I've mentioned.
InCommon is also software. We curate and steward the development of particular open source projects, and we leverage that work. So for some, InCommon means software that people trust is responding to their needs in a way that is consistent with the culture and privacy expectations for academic leaders and academics globally.
So, as I've said, it's a community, it's infrastructure, it's software, and it's also other things to other people. It's very interesting to me, when I attend national meetings, and people I haven't met before ask me what I do, I'll say that I do the kinds of things you would associate with InCommon, and with Internet2. It's really fascinating to see how people light up when they hear the word InCommon. So many people have a connection to it — one that means something uniquely for them.
Grush: What, in general, does InCommon do for CIOs/IT people, and how is that different than what it does for researchers?
Morooney: The origin story of InCommon is rooted in precisely what Ann mentioned earlier: primarily the support for scholarship; for research collaboration in a global context.
But there are value propositions for the infrastructure, the software, and the community that go beyond research. Many of the universities that take advantage of InCommon and what it can do for researchers are also addressing really important and often thorny enterprise and administrative computing needs.
Many of the universities that take advantage of InCommon and what it can do for researchers are also addressing really important and often thorny enterprise and administrative computing needs.
And then there are those things that fall in between administrative computing needs and research needs. So, it's not just the research infrastructure and research capabilities. We often lead with the research community in our narratives, because that is a large part the origin of InCommon. And research problems tend to be the most complex. But InCommon's value actually goes well beyond that.
That's important background for your question, because CIOs run a lot of different infrastructures, and pan-organizational services that start to take on the characteristics of infrastructures. For example, running e-mail and calendaring is not really running an infrastructure, but the need for an institution to do e-mail and calendaring is so pervasive that the service itself takes on the usage and operational characteristics of an infrastructure. And because of that, the connection to InCommon falls under the purview of a campus CIO. I think there's a complete resonance with what a CIO's portfolio is and what it is that InCommon enables.
I think there's a complete resonance with what a CIO's portfolio is and what it is that InCommon enables.
CIOs have to enable identity management as well as access management on campus. Access to course management systems, student information systems, development and alumni systems, grant management systems… all of those capabilities require the ability to be able to determine who can access what, and in what context. That's what identity and access management is all about.
What InCommon does, is to create tools, driven by a community, and infrastructure that you can leverage to solve your local problem.
But the really significant and most important thing about InCommon is that it allows you to use that necessary identity and access capability outside of your administrative domain.
The really significant and most important thing about InCommon is that it allows you to use that necessary identity and access capability outside of your administrative domain.
So if you have a service that's running in the cloud, a service that's being run by another institution, you can expose who has rights to do what kind of things with that third party — in a way that is trustworthy and privacy-preserving.
You have to solve your identity and access management problems on your campus, just in the course of doing normal business. And what InCommon gives you is the ability to extend all the techniques of identity and access management around the world.
What InCommon gives you is the ability to extend all the techniques of identity and access management around the world.
It's an extraordinarily difficult problem, and hardly a day goes by when I don't both thank and sit in awe of people like Ken and Bob and all those who were around that origin table… those who looked at such a complex problem and didn't run away from it. I'm a beneficiary of those efforts from many years ago.
Grush: How did all of this scale over the years?
Morooney: It took about five years to get to a hundred participating institutions. There was a fairly slow uptake. Now it's more than a thousand institutions. It's really difficult — almost impossible — to count the number of individual people. But it isn't hyperbolic or an exaggeration to say that it's an eight-digit number: tens of millions of individuals. It's a huge number of people at all those institutions.
Grush: Getting back to the origin story, could we look at some generalized examples of the most prominent types of use cases?
West: Sure. As Kevin mentioned, InCommon is used for more than just research. There were three basic use cases we looked at back when we were determining what we needed to do:
One is to enable researchers to access services for collaborative projects or data repositories; this is what we would call cyber-infrastructure in the scientific world. These projects might have their data and infrastructure needs hosted on campus or with other agencies off campus, for example, with the National Institutes of Health. So, this is really the research piece.
Another use case is access to organizational resources; for example, student access to a university's learning management system, or LMS. This is what we now call software as a service — SaaS. Examples might be single campus or multicampus, such as a consortium like Five Colleges out of Amherst.
And the third use case we looked at is shared library resources. The key there is to access the resources without giving away any information regarding identity.
So, we were thinking about how we would support all of those different use cases, making sure the end user would have seamless access with something that might look like single sign-on.
For all of these use cases, the security and trust infrastructure belongs to and meets the standards of InCommon. And policy and process (a set of trust infrastructure policies) sits on top of that to make sure it all works. From there, you can map all of this onto the ever-present idea of scaling, which was designed in from the start.
Grush: So is InCommon involved in every interaction? How does this really work, at scale?
West: Neither InCommon nor Internet2 sits in the middle of transactions. InCommon creates an environment — both a technical environment and a community environment — that enables secure and private transactions. That's how we can scale this.
InCommon creates an environment — both a technical environment and a community environment — that enables secure and private transactions. That's how we can scale this.
Grush: I'd like to find out a little more about the workshops or other learning opportunities that might help institutions take advantage of InCommon. What is InCommon Academy?
West: InCommon Academy provides education and community collaboration services to address identity and access management opportunities. And there is a technical side to this, as well as a very important community aspect to it.
Morooney: Right. I think one way to think about InCommon Academy is that it has multiple components.
There's training and upskilling within the InCommon Academy framework. Earlier I mentioned the software context for what InCommon means to people. We bring in passionate subject matter experts to do that training. Attendees bring their unique problems to the table so that they can learn in a relevant, real-time, and really connected way — in a way that matters to them and to their institutions.
We also run community events, including BaseCAMP, CAMP, and Advanced CAMP. We also have the Collaboration Success Program, which is perhaps the highest order component of the InCommon Academy. This is where institutions that are interested in in-depth, intense learning bring their problems to a cohort of subject matter experts. We as Internet2 staff work with them, but the most important thing is that they work with each other. They all learn from each other as they each solve their own problems.
And once a month we do an installment of our webinar series, which informs attendees of matters of interest to identity and access management professionals in higher education.
So, there are layers to the InCommon Academy. Some are really intense, while others are based on a "show up and learn a little bit" style. And there's everything in between. InCommon Academy is an engine for keeping people connected to the community and for keeping the community as vibrant as it is.
InCommon Academy is an engine for keeping people connected to the community and for keeping the community as vibrant as it is.
West: The InCommon Academy is also about sharing expertise and community approaches to identity and access management. It's about understanding what staff need to do to support your institution's mission and then mapping that to the technology to make it happen — giving them the right access to the right systems.
What we've found time and again is that while you can outsource the technology, you can't outsource the policy and business process. By getting involved in the community and comparing notes with your peers, you'll soon find institutions with shared challenges and colleagues with whom you can collaborate and find solutions together. That's the power of leveraging the community.
Grush: Whenever I think of Internet2, I think of a community of people who are invested in the larger picture. Could you share a bit more on how the community engaged with InCommon relates and contributes to InCommon?
Morooney: What you just touched on is something that's incredibly important to the vitality of InCommon. We have a remarkably rich governance and advisory committee structure that helps keep everything moving and keeps our priorities and requirements well-defined.
These governance and advisory groups include: the InCommon Steering Committee; the InCommon Technical Advisory Committee; the Community Trust and Assurance Board; and the Community Architecture Committee for Trust and Identity.
CACTI is a good example of the diversity of input we tap into through our advisory processes. This grouping of identity and access management architects from across the community takes a very broad and high-level view of all of the initiatives we have going on. [See InCommon.org/community/leadership for committee rosters.]
We also have temporary working groups that are spun up from time to time. But at stasis, we are convening several dozen thought leaders from as many institutions monthly or in some cases biweekly, to gather data continuously, refine requirements always, and often inform policy decisions. And the InCommon Academy is a key part of our community development and maintenance.
The InCommon Academy is a key part of our community development and maintenance.
In my opinion the secret sauce, and one of the most rewarding parts of my job, is working with those people who participate in our standing advisory bodies as well as those who contribute through the many opportunities for community engagement.
All of that is where you really begin to understand the passion behind InCommon.
[Editor's note: Ann West is Internet2's AVP for trust and identity; Kevin Morooney is the Internet2 vice president of trust and identity and NET+ programs. Along with this Q&A on InCommon, be sure to see our other Internet2 25th anniversary features focusing on next generation infrastructure, NET+, and technology and community.]