Guest Expert
Nataraj Nagaratnam
Chief Architect for Identity Management
IBM
Nataraj Nagaratnam

As the Chief Architect for Identity Management and Lead Security Architect for On Demand Security Infrastructure and Technical Strategy at IBM, Nataraj Nagartnam has witnessed firsthand the maturation of Grid security technologies – both in the research world and the commercial / enterprise world. In a recent interview with the Globus Consortium Journal, Nagaratnam brings readers up to speed on the CredEx Project, and outlines some specific security challenges that the Grid community is working hard to address today.

GCJ: Can tell us about the CredEx Project and the challenges it sought to address?

Nagaratnam: CredEx is an open source, standards-based Web Service that facilitates the secure storage of credentials and enables the dynamic exchange of different credential types using the WS-Trust token exchange protocol.

CredEx showcased that WS-Trust can actually be used to transform between GSI credentials and other token formats, like SAML and interoperate with other web services platforms like WebSphere. With CredEx, we were able to leverage the WS standards to provide an interoperability layer to the Grid environments that use the Globus Toolkit. The intent of CredEx was not necessarily to completely develop commercial software per se, but to provide proof points to foster Grid community buy-in into WS-Star.

GCJ: How does CredEx relate to the Simple CA and MyProxy efforts?

Nagaratnam: You can view CredEx as more of a credential exchange mechanism on the server side, and aligned with MyProxy. As a matter of fact, the design and implementation of CredEx is inspired by MyProxy, the critical differences being that CredEx supports more than just the password-to-Grid Credential (GSI) exchange and that CredEx is compliant with emerging Web Services security specifications and standards, specifically WS-Trust.

GCJ: Can you tell us a little bit about the identity-aware application and security efforts you are working on?

Nagaratnam: Digital Identity is an online representation of users, groups, organization and devices and maybe used in transactions, collaborative computing and social networking. Given the multiple identity systems that participate in everyday online activities – transactions, collaboration, sharing – across companies, governments and social networks, an identity framework is necessary so that identity information can be federated across multiple identity systems.

And as you probably saw earlier this week, IBM and Novell jointly announced an open source initiative for building an online, user-centric identity management system.

When you consider threats like identity theft and phishing - and the new security implications of social networking and collaborative computing - there's a lot of identity information out there today, managed by different systems and institutions. From an end user perspective, we are concerned about identity being lost or accessed by a non-trusted party. And from companies' perspectives, they're worried about reputation.

So user-centric identity management is the next big wave in Internet security. It allows end users to actively manage their identity information. This is also about making multiple identity systems and policies interoperable. So we're looking at open source as a foundation so that a community of developers can work with user-centric identity, and no one gets locked into a proprietary system.

This Higgins Trust Framework can integrate with open LDAP, or IBM's directory server, or Novell's directory server, or Active Directory. And the identity information isn't only in LDAP directories -- it can be in human resources systems, like People Soft, from an enterprise standpoint. Or even on my cell phone, maybe I want to integrate my buddy list with my Yahoo or LinkedIn.

So we're looking at an identity meta system that can be built on open standards and open source, where other multiple identity systems can be plugged in -- an identity infrastructure for the Internet.

GCJ: One of the discussions taking place around application development is people favoring the “P” languages (Perl, Python, PHP) for certain application development requirements. Do you see any sort of acceleration in the use of the “P” languages in Grid computing?

Nagaratnam: There is definitely a lot of interest in PHP and the entire LAMP area, and IBM does work in those areas as well with our products like Geronimo and even WebSphere. Also, we are moving to a service component architecture which allows us to assemble services where each service may be implemented in a manner that is familiar to that person. But it is not really a J2EE replacement discussion.

But from an enterprise application viewpoint (business logic and access to business data), I think J2EE platforms still will continue. And if certain applications are written in Java or PHP, they should be accessible through a Service Oriented Architecture (SOA) and thus in a language-agnostic way.

GCJ: Can you give us a quick update on where you perceive to be the vulnerabilities for Grid security today … the areas that perhaps have not been perfected on the security front that require some additional work in the next couple years?

Nagaratnam: The traditional security needs around authentication, and authorization have been addressed quite well, and have enough focus. The aspect of delegation is starting to be addressed in some discussions in the security community, and there is more to be done there. With increasing regulation controls and compliance needs, the need for audit becomes more important.

With respect to the vulnerabilities, I think the aspect of isolation continues to be challenging, be it in Grid environment i.e., distributed computing environment. We continue to work on isolating application data and identity where multiple identities access the same application. For example, if you have multiple applications on the same middleware, but are accessing different data sources, you don’t want the data to be accessed -- even accidentally -- by the other one. Isolation is really key.

Today, much of the isolation is definitely at the process level. In fact, most of the practical deployments are not only at the process level, but maybe at the physical box level. But when it comes to process level isolation, then there are a lot of control and capabilities and platform considerations (like the OS) that come into play. How do you isolate the same job or multiple jobs running across all different organizations or entities?

close window