Large-scale grid computing environments are complicated, involving many users, data and computational resources, network channels and administrative domains. This complexity makes it hard, if not impossible, to describe all of the entities and relationships required to provide access control using existing approaches which lack formal mechanisms for describing and evaluating security policies. To date, there has not been a simple, flexible language available to navigate these complex security issues associated with distributed computing environments.

Microsoft has recently focused on this problem and developed a solution called the Security Policy Assertion Language (SecPAL). The project — undertaken by the advanced technology incubation group of Microsoft’s Chief Research and Strategy Officer and Microsoft Research Cambridge — resulted in a declarative, logic-based language providing comprehensive support for:

• Describing  trust relationships both within and across organizational boundaries.

• Expressing principal identities and attributes capable of being authenticated.

• Creating  access policies which help describe the desired access to a variety of services and resources.

• Controlling delegation of rights, allowing one principal to allow another to exercise a subset of their rights in a specific context.

• Expressing audit policies which can capture critical security decisions and support forensic analysis.

To help demonstrate the unique SecPAL approach and the capabilities above, we have outlined a simple use-case below in which we describe the policies necessary to allow a user from within a virtual organization (called Research Grid VO) to submit grid jobs to a computational cluster in an external organization (called the Center for High-Performance Computing). The scenario is illustrated in Figure 1.

A fundamental concept within SecPAL is the security assertion, a statement made by a principal that may: define a binding between a principal and an attribute; specify a principal’s permissions to operate on a resource; express a trust or delegation policy; express an authorization policy; revoke a prior assertion; or declare principal identifier alias relationships.

In our example, the Master Scheduler could establish a trust-relationship directly with our end-user Bob. However, this interaction quickly becomes unmanageable for any sizable environment. Rather, the common practice is for CHPC to establish a trust relationship with an authority, such as the Research Grid Security Token Service (STS), responsible for certifying grid users.

Example 1 illustrates such a policy whereby the CHPC administrator expresses that he trusts the VO-ResearchGrid-STS to make assertions about the grid’s users. In this case, he trusts the STS to identify grid users and their rfc822 email names (certifying those are true for up to one year). Here, we use a SecPAL simplified English grammar for readability. The Microsoft implementation also supports serializing such policies as XML for cross-platform interoperability.

CHPCAdmin says VO-ReseachGrid-STS can say %p possesses %a (from %t1 until %t2) where

       %t2 – %t1 <= "366.00:00:00",
       %t1 <= CurrentTime() <= %t2,
       %a matches rfc822Name:”.*@contoso.edu”

Example 1: Policy establishing a trust relationship between CHPC and the Research Grid Virtual Organization

This policy includes variables, another important concept within SecPAL. Variables are substituted for concrete values at policy evaluation time. In this policy, variable “%a” represents an attribute which must match the given rfc822 e-mail name pattern, the %p variable represents any principal, and the variables %t1 and %t2 represent date-time values which are constrained to represent a time-span of no more than 366 days.

The CHPC master scheduler would have a local authorization policy controlling who may use the job management services. This typically will rely on the organizational trust policy because the scheduler service administrator typically won’t be responsible for cross-organizational relationships. Given the above trust policy, the scheduler administrator could write the local authorization policy to restrict access based on the rfc822 names of principal’s requesting use of the job management services. It would only believe such names if they are certified by an authority trusted by the CHPC  administrator. For example, if only users with rfc822 names in the contoso.edu domain are authorized, the policy would look like:

CHPCAdmin says %p can execute service:”http://www.chpc.org/scheduleJob” if

       %p possesses %a
 where
       %a matches rfc822Name:” .*@contoso.edu “

Example 2: Policy restricting access to the job scheduler

For our user Bob to schedule a job, he first needs to obtain an identity token from the Research Grid STS, which contains his e-mail name. This might require he authenticate using a Contoso-supplied authentication credential (such as an X.509 certificate, Kerberos token or SAML token), which is accepted by grid services. The grid token obtained from the STS would contain the assertion:

VO-ReseachGrid-STS says Bob possesses rfc822Name:”[email protected]”
        (from “2007-01-01” until “2007-12-31”)

Example 3: SecPAL token used by Bob for authentication

Now Bob can submit a request to initiate a job on the CHPC cluster by sending an authenticated message containing his SecPAL token along with the job information needed by the CHPC master scheduler. The scheduler can then formulate a SecPAL query similar to that shown in Example 4, which would evaluate Bob’s credentials against the CHPC security policies, thus allowing the scheduler to allow Bob’s job to be scheduled.

CHPCAdmin can execute service:”http://www.chpc.org/scheduleJob”?

Example 4: Authorization Query generated by CHPC Scheduler to verify access rights

Bob also can take advantage of SecPAL to formulate a delegation of his rights to access a data file on a server at Birch University, where the job data may reside. For example, the right for the master scheduler to delegate the right to read “jobData” can be expressed as the first policy in Example 5, which Bob can supply with his job request. The scheduler can then delegate that specific access to the job when it’s run as in the second assertions. The file service at Birch University can then use the second assertion in Example 5 to authorize Bob-Job to read the file because it can deduce Bob has authorized the delegation of this right.

Bob says Scheduler can say %p read file://BirchFileShare/jobData (from %t1` tio %t2) if %t2-%t1<5 days Scheduler says Bob-Job read file://BirchFileShare/jobData [from 2007-04- 28 to 2007-05-01]?

Example 5: Simple delegation of a single user access right

This example demonstrates some of the power and flexibility of SecPAL to address important grid security needs in a straightforward manner. Independent assessment and experimentation is now an important next step in SecPAL’s development to ensure it will meet the industry’s needs for a flexible, robust and high-assurance security solution. Professors Martin Humphrey of the University of Virginia and Panos Periorellis of University of Newcastle Upon Tyne (England) have begun investigating the benefits of SecPAL. Initial results indicate SecPAL enables a fine-grained, dynamic and delegation-aware mechanism capable of easily coping across organizations with a wide variety of different security policies, and further enabling increased interoperability in distributed computing environments.

Microsoft is now making its implementation available to other researchers to experiment with the SecPAL approach to addressing grid security requirements. Researchers interested in evaluating SecPAL can go to http://research.microsoft.com/projects/secpal for more project information. The .NET implementation, sample code for a number of common authorization patterns and community site facilitating discussions about the use of SecPAL can be found at www.codeplex.com/secpal. Microsoft hopes to collaborate with grid computing communities to develop a viable and comprehensive security solution for grid computing that promotes continued interoperability.