GCJ: So could you give our readers a brief explanation of GridShib and its history?

Welch / Siebenlist: GridShib grew out of some ideas that Frank and I had a couple years ago. At that time, obviously the grid community was growing and putting a lot of work into the setting of PKIs and X.509 infrastructures at that point. Within higher education, the Internet2 community was simultaneously working on middleware, in particular this product called Shibboleth, which helps universities share Web resources between themselves. Shibboleth is actually a Web browser-friendly identity management application that lets schools standardize their existing identity management infrastructure so that other campuses can authenticate and authorize their users to access local Web resources.

Our thought was this: if campuses all over are adopting Shibboleth to facilitate authentication of their users, we could leverage Shibboleth to give its existing users access to highly scalable, grid resources using only their local campus authentication. So we set out to make Shibboleth features available for the grid level protocols.

Eventually, we got some funding from the NMI Program of the National Science Foundation. And then we started work about 18 months ago. So that was the start of GridShib.

GCJ: Could you briefly explain how Shibboleth and GridShib actually work?

Welch / Siebenlist: Shibboleth is what's called a single sign-on service and attribute authority. What we've developed is a set of tools that enables Shibboleth, which was initially designed to access Web applications through browsers, to access grid services, which are obviously based on the Web services standard. They use SOAP, they typically have command line clients, and so forth. All told, it's a very different world than the browser world that Shibboleth was originally created for.

Our tools bridge the gap. GridShib allows users to get an X.509 certificate based on Shibboleth authentication, and then use that X509 certificate to access the grid service. The grid service, meanwhile, can refer back to Shibboleth and get attributes about that user. And so it allows grid services to leverage the information that's already known about Shibboleth users to authenticate and authorize that user.

In terms of how it all actually works, the service can be broken down into several components. A product we have called GridShib CA allows Shibboleth authentication to be translated into X.509 certificates. Our certificate registry actually binds those X.509 identities to Shibboleth identities. And then we have an attribute name-mapper plug-in that allows grid attribute queries to be made back to the Shibboleth service. Plus, we have the various Shibboleth extension points that allow Globus services to make queries to Shibboleth, receive the SAML-formatted attributes in return, and then parse them.

And then we've done some work above and beyond all that, in collaboration with our colleagues down at University of Alabama at Birmingham, Jill Gemmill and John-Paul Robinson. They've helped us combine GridShib with their work on myVocs to help people set up virtual organizations, and then use Shibboleth to access grid resources.

GCJ: Right. Regarding applications like myVocs, what do you think makes GridShib so apropos?

Welch / Siebenlist: The most salient benefit Gridshib offers is really the reuse of existing identity management infrastructure for Shibboleth-enrolled users. Quite often, the first and most significant problem grid users encounter when jumping on a grid is simply getting their security credentials. Security is extremely important in the grid context, but users shouldn't have to go out and get another security credential. And with Gridshib, they don't have to go learn another pass phrase or go get an X.509 credential. They are, in a sense, already authorized to get going.

We're working with several different projects right now focused on leveraging that scalability. We are working with nanoHUB: a VO for the nanotechnology community led by Purdue University. They want to leverage their site of identity and attributes to access grid resources such as a TeraGrid. To that end they have deployed shibboleth and are now integrating GridShib.

In addition to the nanoHub project we are working closely right now with TeraGrid with respect to the overall authorization architecture of the facility. TeraGrid' objective is to make campus user access to TeraGrid resources both more secure - leveraging campus authentication infrastructure - and more convenient - leveraging campus authorization systems.We're hoping that Shibboleth can authenticate and authorize lots of users on many campuses, thereby solving what was otherwise a formidable scalability problem.

GCJ: Could you tell us a little bit more about one of your collaborative projects?

Welch / Siebenlist: Of course. Let me tell you more about myVocs. The myVocs package allows the autonomous creation of virtual organizations based on Shibboleth. Essentially, myVocs aggregates enterprise-provided identity asserted by multiple Shibboleth-based organizations with virtual organization provided attributes such that their collective users can, say, collaborate on academic research without having to create any additional authentication mechanisms. And by using GridShib through myVocs, this academic working group could securely access assigned web-based and grid resources located in any domain. In such a case, identity federation would actually require translations: the user's campus name would be traced to the name by which they're known by in the virtual organization, which would, in turn, be translated into a X.509 DN.

myVocs handles the first translation just through the use of its internal databases when a user registers. The second translation, from myVocs into the grid domain, is processed by our certificate registry service, which is a Gridshib product that sits on the myVocs Shibboleth server. It allows an X.509 user to assert their X.509 certification through the standard Shibboleth authentication process. The Shibboleth server then binds those two names for the purpose of future identification. Since the Shibboleth server can recognize that a particular X.509 identity is bound to a specific local identity, it can feed back the appropriate attributes to that user.

GCJ: I see. Could you summarize the current state of Gridshib, and perhaps where you envision going?

Welch / Siebenlist: Sure. About six months ago we released a set of beta add-ons that we've been using recently, particularly in our work with nanoHub. They're add-ons to the Globus 4.0 Toolkit and the Shibboleth 1.3 release, so anyone is free to install either GT4 or Shibboleth 1.3 and then add our tools on top.

They are still beta for several reasons. Of course we're keeping the design fluid as we continue to realize and fulfill the needs of our user communities. And then they're also evolving because Shibboleth is based on a Web services security standard called SAML, which is also still evolving.

SAML actually just made a major evolutionary step with the release of the SAML 2.0 specification. Following that, Shibboleth began working on their 2.0 release, which gave us the opportunity to work with the Shibboleth developers directly, rather than adapting Gridshib to their product after-the-fact. So look for future versions of Gridshib to integrate with Shibboleth 2.0 and, of course, the upcoming Globus 4.2 release.

GCJ: What kind of problems or opportunities or findings have affected your development over the last few months?

Welch / Siebenlist: The primary problem that we're facing here is one of identity federation: users have established identities on the campuses, but the grid knows them by another set of identities, their X.509 distinguished names. This is illustrated with our work on the TeraGrid project - and one of the trickiest problems we've faced is how to correlate names with X.509 certificates. Who makes that connection? How is that maintained? And how do others confirm that that match is actually correct?

Now we've got whole services that we've developed just to allow for these name bindings to take place. In retrospect, maybe it isn't so surprising that in this federated world where we are all known by many names, name mapping has turned out to be a vital, if somewhat painful, part of our development.

GCJ: Is the naming issue as problematic in enterprise as it is in higher education?

Welch / Siebenlist: Yes. Crossing administrative or mechanism boundaries will trigger this problem. Shibboleth actually crosses both: from within the campus to without, and from the Shibboleth SAML world into X.509.

In enterprise, the same issues apply. Users are known by certain identities within their enterprise, but when they engage another organization, odds are they're going to be identified by yet another DN. Then again, you face the same host of identity federation challenges.

GCJ: It sounds like a lot of people might be interested in Gridshib. Do you have any feel for how many users or organizations are deploying GridShib now?

Welch / Siebenlist: We're still getting going, so we've got adoption from nanoHub right now, but we're still working with them and look for other first adopters.

In terms of exposure, we are really looking forward to the release of the Globus Toolkit 4.1.1 because Gridshib will be included and configured right out-of-the-box! We're excited about having GridShib functionality being standard with new Globus Toolkit releases.

Editors Note: Frank and Von are hosting a plethora of Security Sessions at GlobusWORLD / GridWorld this month.

close window