GCJ: From a developer's perspective, what are some of the specific security challenges that the Grid applications are introducing?
Siebenlist: The biggest challenge is how to cross administrative domains in a well understood way. As a programmer, security becomes much more complicated when you have to adhere not only to your own policies, but also to the policies in an external domain where you share your resources. You have to find a way to enforce these different policies in a consistent way, and that's a challenge.
GCJ: What are some of the most important Grid security standards to watch?
Siebenlist: Anything that has to do with policy is very important. That includes things like attribute and identity federation - where Liberty Alliance, Shibboleth and SAML play a big role. Probably the most important area within policy is how to express it - the policy language, the authorization (or the access control) languages. And how you connect to them is also very important -- meaning, what are the standards to call out to an authorization service to find out whether access is permitted. In this context, XACML is the standard that's most important to us right now (another OASIS standard).
And we have some standardized "call out" interfaces. These are interfaces where you can call out to an external authorization service to determine whether access is permitted by any requester that comes to your service to invoke an operation on your resources. All of these right now are implemented in the Globus Toolkit - we're able to deal with SAML assertions, we're able to call out through standardized authorization queries (that have been developed in OASIS, as well as in GGF), and we have an XACML authorization engine embedded into the Globus Toolkit that can be turned on. On top of that, we also deal with the X.509 Attribute Certificates, which are cousins of the X.509 identity certificates, and are used to assert group memberships and roles, and some of our community use those to express group memberships.
I think it's good to understand that these standards - like WS-Security - are on a very low level. Conceptually, the security world, we're still working on the TCP/IP level, and it's moving very slowly up the stack, and too slowly for us. We have a real problem ... we'd like a lot of these standards to be more mature and standardized.
GCJ: What about scheduling issues -- how do those affect Grid security?
Siebenlist: I think what makes securing Grid services a little different than securing plain vanilla web services is that with many Grid services, there are middle men in the picture - the users do not directly interact with the resources. There are all kinds of intermediates, like discovery and broker services, that find out where the available resources are. From a security point of view, it adds the problem of delegation of rights -- meaning, these services have to be empowered by the user to act on their behalf. In an ideal world, you would like to be able to express the delegation of rights in a fine-grained way. You don't want to give out a blank check to any one of these intermediates; you want to confine the rights to those middlemen to only what is needed to do the job, and no more. We call that a lease-privilege delegation of rights.
We use these X509 Proxy Certificates - that have been standardized in the IETF - as a way to express the delegation of rights. Unfortunately, currently they only do it in a coarse-grained way. In addition to these proxy certificates, we need policy languages that express those rights in a finer-grained way. We are now working on combining these proxy certificates with languages like SAML and XACML to confine the rights in a very concise way. And unfortunately, we are running ahead of the crowd. The plain vanilla web services world does not need these services yet. As a consequence, there are no real standards yet, and we have to figure it out ourselves. Hopefully 2-4 years down the road, this will all be part of the normal ws-plumbing that is provided by the vendors, and we can focus with our Globus Toolkit further up the stack, on the application problems.
GCJ: What about the need for paper trails and auditing?
Siebenlist: That's a good point. That's one of the weaknesses that we have - the standardization of secure logging and audit trails. It has been identified as something that has to be addressed, and we've started work in GGF to do that. But if you look at OASIS or other standards organizations, there are no efforts underway right now that standardize, audit and facilitate the reconciliation of different audit trails that are distributed along different organizations. It's all sort of ad hoc-ed, which makes it extremely difficult to browse these audit logs if they are all in different formats, in different administrative domains, and the whole access control has to be resolved in order to match the different audit entries into different audit logs and different administrative domains. It's extremely difficult to reconstruct a thread of work through all these services. Right now that's an issue. A lot of things are logged in all kinds of different points, but what we need is a standardized format and tool that can reconcile and reconstruct the thread of work for auditing purposes.
close window |
|