A Flexible Attribute Based Access Control Method for Grid Computing

Download PDF
10 downloads 2064 Views 293KB Size Report
Comment
Nov 20, 2008 - of building a flexible access control mechanism that is based on ABAC and supports multiple policies for Grid computing. Firstly an attribute.
J Grid Computing (2009) 7:169–180 DOI 10.1007/s10723-008-9112-1

A Flexible Attribute Based Access Control Method for Grid Computing Bo Lang · Ian Foster · Frank Siebenlist · Rachana Ananthakrishnan · Tim Freeman

Received: 20 March 2008 / Accepted: 3 November 2008 / Published online: 20 November 2008 © Springer Science + Business Media B.V. 2008

Abstract Grid systems have huge and changeable user groups, and different autonomous domains always have different security policies. The attribute based access control (ABAC) model, which is flexible and scalable, is more suitable for Grid systems. This paper describes a method of building a flexible access control mechanism that is based on ABAC and supports multiple policies for Grid computing. Firstly an attribute

B. Lang (B) · I. Foster · F. Siebenlist · R. Ananthakrishnan · T. Freeman Mathematics and Computer Science Division, Argonne National Laboratory, Argonne, IL USA e-mail: [email protected] I. Foster e-mail: [email protected] F. Siebenlist e-mail: [email protected] R. Ananthakrishnan e-mail: [email protected] T. Freeman e-mail: [email protected] B. Lang State Key Lab of Software Development Environment, Beihang University, Beijing, China I. Foster · F. Siebenlist · T. Freeman University of Chicago, Chicago, IL, USA

based multipolicy access control model ABMAC is submitted. Compared with ABAC, ABMAC can describe multiple heterogeneous policies, and each policy is encapsulated without changing its descriptions. Then by extending the authorization architecture of XACML, the paper puts forward an authorization framework that supports ABMAC and is implemented in the Globus Toolkit release 4 (GT4) (Few parts of the authorization framework described in this paper can only be found in Globus Toolkit CVS repository. A more completed authorization framework will be appeared in the Globus Toolkit release 4.2). Basing on the concept of policy encapsulation, the framework provides a flexible and scalable authorization mechanism that can support multiple existing policies in a Grid system. The design and implementation details of GT4 authorization framework are also well discussed. Keywords Attribute-based access control (ABAC) · Attribute-based multipolicy access control (ABMAC) · Grid computing · GT4 authorization framework

1 Introduction Access control as an important protection mechanism in computer security is evolving with the development of applications. Since the early

170

1970s, several access control models have appeared, including discretional access control (DAC), mandatory access control (MAC), and role based access control (RBAC) [1–3]. These models are considered identity based access control models, where subjects and objects are identified by unique names and access control is based on the identity of the subject, either directly or through roles or label assigned to the subject. DAC, MAC and RBAC are effective for closed and relatively unchangeable distributed systems that deal only with a set of known users who access a set of known services. Since the late 1990s, with the development of Internet-based distributed systems, a new access control model—the attribute based access control (ABAC)—has appeared. In ABAC, access decisions are based on attributes of the requestor and resource, and users need not to be known by the resource before sending a request. ABAC is becoming increasingly important especially in Web Services based applications; Web Services security specifications like extensible access control markup language (XACML) and security assertions markup language (SAML) have been established that support ABAC. A Grid system is a virtual organization (VO) comprising several independent autonomous domains (AD) [4]. The relationship between resources and users is more dynamic, resource providers and users are not in the same security domain, and users are usually identified by their characteristics or attributes rather than predefined identities. Therefore, the traditional identity based access control models are not so effective and ABAC shows great advantages. Also, Grid systems have special authorization problems. In a Grid, each AD has its own policy model and mechanism that may different from other ADs. Hence the authorization mechanism of Grid need to be flexible to support multiple security policies, which makes it more complex than other distributed systems. How to establish an attribute based authorization framework that supports multiple types of security policies is a new problem need to be solved. Globus is the leading Grid computing platform in the world. Much work has been done on this problem [5]. Basing on ABAC and the special

B. Lang et al.

requirements of Grid, we submit an attribute based multipolicy access control model ABMAC that can support multiple policies without changing the description and evaluation mechanism of various polices; also by extending the XACML authorization model and integrating SAML, we build a flexible authorization framework that supports ABMAC. This attribute-based authorization framework supports several different policies and can integrate third-party attribute-based authorization systems. The paper is organized as follows. Section 2 surveys the research of attribute-based access control models. Section 3 describes the special access control requirements of Grid computing, and presents our attribute based multipolicy access control model (ABMAC). Section 4 describes the design and implementation of the GT4 authorization framework, which is in accordance with the ABMAC model. Section 5 analyses the advantages of the framework for Grid computing and summarizes our work.

2 Related Work Since the early 1990s, with the development of Internet and Internet-based distributed application, public-key infrastructure (PKI) and X.509 certificates [6, 7] have been widely used for authentication [8]. In 1996, the simple public key infrastructure (SPKI) was developed, which is a kind of PKI that emphasizes on authorization rather than authentication [9]. SPKI is one of the earliest attempts to define an authorization certificate [10]. In 1997, the attribute certificates (AC) was included in X.509 [11]. An AC may contain attributes that specify group membership, role, security clearance, or other authorization information associated with the AC holder [12]. Recent research and development efforts in attributebased access control are based on the X.509 ACs. A first attempt to provide a uniform framework for attribute based access control specification and enforcement was proposed by Damiani et al. [13]. They presented a uniform framework to logically formulate and reason about both service access and disclosure constraints based on related entity attributes [14]. Wang et al. [15] proposed a

A flexible ABAC method for Grid computing

framework that models an attribute-based access control system using logic programming with set constraints of a computable set theory. Recently, Yuan and Tong [16] described the attribute-based access control model in terms of its authorization architecture and policy formulation. In addition to the research in theory, the practice of ABAC in Grid computing is also very active [17]. Several systems have appeared, such as Akenti, PERMIS, Shibboleth, and VOMS. Akenti, developed by Lawrence Berkeley National Laboratory [10, 18], represents the authorization policy for a resource as a set of certificates digitally signed by unrelated stakeholders from different domains. These certificates express the attributes a user must have in order to get specific rights to a resource. PERMIS, developed under the EC PERMIS project, is a role-based access control infrastructure based on X.509 PMI and using X.509 attribute certificates [19, 20]. The project developed a policy-driven decision engine and defined a policy language using XML. Shibboleth is an attribute authority service developed by the Internet2 community for cross-organization identity federation; it asserts attributes about a user and can make access decisions based on these attributes [21, 22]. VOMS, developed by the European Data Grid and DataTAG projects, runs in a virtual organization, manages authorization information about its own members, and supplies this information as a kind of attribute certificate [23]. Akenti, PERMIS, and Shibboleth are effective ABAC systems and have been used in many Grid systems. However, these authorization systems support their own policies and are incapable of supporting multiple different policies. As ABAC is widely used in service oriented architecture (SOA) based applications, specifications related to ABAC were published. XACML and SAML are access control-related Web services standards that support attribute-based access control [24, 25]. XACML provides a basic authorization architecture; and SAML, which defines a framework for exchanging security information such as authentication and authorization decisions in XML format, is the technology for integrating existing authorization systems. These two specifications play important roles in the research and application of ABAC.

171

XACML defines a policy language using the attributes of requestors, resources, and environment. Also XACML provides an authorization architecture which supports attribute-based access control [24]. The access control framework contains policy enforcement point (PEP), policy decision point (PDP), policy information point (PIP), and policy administration point (PAP). The PEP intercepts the access requests from users and sends the requests to the PDP. The PDP makes access decisions according to the security policy or policy set written by PAP and using attributes of the subjects, the resource, and the environment obtained by querying the PIP. The access decision given by the PDP is sent to the PEP. The PEP fulfills the obligations and either permits or denies the access request according to the decision of PDP. In present ABAC research and implementations, people are doing work around two problems—policy description and evaluation. By regarding the identities, security labels and roles as the attributes of the relevant entities, ABAC policy languages or policy description structures have the ability of defining different kinds of security policies such as DAC, MAC or RBAC. From this point of view, ABAC can support different policies, and the method it uses indeed is to transform the description of these traditional policies into ABAC policies and using a uniform mechanism to evaluate them. A Grid system is composed by ADs. Each AD may have its own security policy. When constructing a Grid, in many circumstances, it is more effective and flexible for the ADs to build the Grid authorization function basing on their existing access control systems, rather than changing the policy description and build a new one. Hence, how to build an ABAC system that can support multiple types of policies without changing the policy description and evaluation mechanism is a special authorization problem in Grid computing, and also a new problem to ABAC research. 3 An Attribute-Based Multipolicy Access Control Model for Grid Computing In this section, the meaning of attribute-based multipolicy access control in Grid is further

172

B. Lang et al.

platform such as Globus needs to be flexible to support multiple policies. For building such a flexible authorization mechanism, we define an attribute based multipolicy access control model, in which each policy such as Grid-Map-file based authorization and user identity based authorization is encapsulated into an independent unit without changing its description and evaluation algorithm, and is used as a component in policy description.

analyzed, and then the definition of ABMAC model is given, followed by a scenario that uses the model to describe a policy. 3.1 Attribute-Based Multipolicy Access Control in Grid There are two levels of control in a Grid system. The top level is the Grid system i.e. the VO, and the second level is the autonomous domain, shown in Fig. 1. The organizers of the VO sit together and define the VO security policy, and an authorization mechanism needs to be built to enforce the policy. An effective way to build the Grid authorization mechanism is to map the VO security policy on to the policy of the AD that already in use, and invoke the existing local authorization systems to evaluate the policies. The security policy of an AD is called local policy. Since each AD has the right to use a kind of policy according to its security requirements, such as Grid map file authorization, host based authorization or user identity based authorization, the local policies in a VO may be heterogeneous. Hence the access control mechanism of a Grid

3.2 The Definition of ABMAC In ABMAC, access control decisions are made based on the attributes of the requestor, the resource, the action, and the environment. The definition of ABMAC is composed of three parts: access control related entities, attributes of entities, policy description. 1. Access control-related entities •

Fig. 1 Multipolicy access control in Grid

Requestor Req A requestor is the entity that sends requests to the Grid service and invokes actions on the service.

Virtual Organization (VO) VO Security Policy Local Policy (RBAC)

Local Policy (ABAC-XACML) Mapping2

Mapping1

AD2

AD1

Mapping3 Local Policy (HostBased)

Local Policy (GridMapFile)

AD3

A flexible ABAC method for Grid computing

•

•

• •

Service Sev A service is a Grid service that is a software agent with a network-addressable interface containing some well-defined operations; it can be invoked via standard protocols and data formats [26]. Resource Res A resource is a system entity that is acted upon by one or more Grid services. In Grid computing context, resource is always stateful; that is, has a specific set of state data expressible as an XML document and a well-defined lifecycle. Examples of stateful resources are files in a file system, rows in a relational database, and encapsulated objects such as Entity Enterprise Java beans. Action Act An action is an operation provided by a Grid service that can be invoked by clients. Environment Env Environment is the context related to an invocation of a Grid service. It contains information that is not associated with any specific entity but might be useful in the decision process, such as the current date and time.

2. Attributes of entities Each entity has attributes that define the identity and characteristics of the corresponding entity. We define the attributes of the entities in ABMAC as follows: •

The attributes of the requestor may contain the identifier, the name, the organization, and the other information of the requestor and are defined as follows: Attr (Req) = {Req Attri |i ∈ [1, I] }

•

•

The attributes of the service may include the service name and address and are defined as follows:    Attr (Sev) = Sev Attr j j ∈ [1, J] The attributes of the resource may include resource name, identifier, and other information and are defined as follows: Attr (Res) = { ResAttrk | k ∈ [1, K]}

173

•

The attributes of an action can be an action name, for example, and is defined as follows: Attr (Act) = {Act Attrl |l ∈ [1, L]}

•

The attributes of the environment Env may be the current date or time and are defined as follows: Attr (Env) = { Env Attrm | m ∈ [1, M]} I, J, K, L, and M in these definitions are the maximum number of attributes of the corresponding entities and are integers; their values are identified by the context of concrete applications.

3. Policy description The authorization systems of Grid computing need to support multiple security policies, each of which may have its own policy description method. In ABAC, various policies, such as DAC, MAC and RBAC, are described by using one policy language, which will create a new description for these policies. To ensure the integration of different policies and to make ABMAC more scalable, we encapsulated each policy as an independent unit, in which the original description of the policy is remained. The Policy of ABMAC is composed of sub-polices not rules, which is different from the way of policy definition in other models. Policy of ABMAC which decides on whether a requestor Req can invoke the action Act of the resource Res in the environment Env, is a Boolean function of Req,Res, Env, Act: ABMAC_Policy: canAccess(Req,Res,Env,Act) ← combine_ f (Policy_ 1(Req, Res, Env, Act), Policy_ 2(Req, Res, Env, Act), . . . . . . Policy_n(Req, Res, Env, Act));

(1)

Policy_i : canAccess(Req, Res, Env, Act) ← f _ policy_i(Attr(Req), Attr(Res), Attr(Env), Attr(Act)), i = 1, 2, . . .n.

(2)

174

B. Lang et al.

Distinguished Name and the public key can be the following two attributes:

From formula (1) and formula (2), the policy of ABMAC can be described as follows:

ReqAttr1 = Attribute (name=“x509SubjectDN”, value=“CN = requestor1”) ReqAttr2 = Attribute (name=“hostIP”, value= “202.112.136.88”) Attr(Req) = {Reqattr1, Reqattr2}

ABMAC_Policy : canAccess(Req, Res, Env, Act) ← comb ine_ f ( f _ policy_ 1(Attr(Req), Attr(Res), Attr(Env), Attr(Act) f _ policy_ 2(Attr(Req), Attr(Res), Attr(Env), Attr(Act))

•

... ... f _ policy_n(Attr(Req), Attr(Res), Attr(Env), Attr(Act)))

(3)

combine_f(), which combines the decision results returned by each policy policy_i (i = 1,2,. . . ,n) and makes a final access decision. If the evaluation result of combine_f() is true, then the request to the resource is permited; otherwise the request is denied. The rules of policy_i (i = 1,2,. . . ,n) is encapsulated in the policy and need not to be described in ABMAC. policy_i is defined by a Boolean function f_policy_i() which takes the attributes of Req,Res, Env, Act as parameters, and its result set is {permit, deny}.

ResAttr1 =Attribute (name=“portType”, value=“fileTransferPortType”) ResAttr2 =Attribute (name=“resourceId”, value=“#%%@resrcId$$%#”) Attr(Res) = {ResAttr1 , ResAttr2 } •

1. Entities and attributes definition •

The requestor Req X.509 End Entity Certificates are widely used in Grid computing. If the X.509 End Entity Certificate is used for the authentication of a requestor, then the requestor’s

The action Act The action is the operation defined in a service port type: ActAttr1 =Attribute (name=“operation”, value=“readFile”) Attr(Act) = {ActAttr1 }

3.3 Using ABMAC to Describe a Policy In a Grid system, an authorization system is always established to guard one Grid service. In the following scenario, the attributes of the requestor, the resource, the action, and the environment will be used to make an access control decision. We use a data structure named Attribute, which contains the attribute name and attribute value to describe an attribute.

The resource Res According to the WSRF specification [27], a WS-resource is composed of a Web service and several stateful resources. A resource is associated with one or more WSDL portTypes, by which the resource can be operated by the Web services. We define the resource as follows:

•

The environment Env The environment contains the current time as the attribute: EnvAttr1 = Attribute (name=“currentTime”, value=“21:57:08.03”) Attr(Env) = {EnvAttr1 }

2. Policy description If two kinds of policy including host based policy and user identity based policy need to be used when making an access control decision, and the function combine_f() is defined as the requestor can invoke the action only

A flexible ABAC method for Grid computing

when these two policies return permit, then the policy of ABMAC should be defined as follows according to formula (3): ABM AC_Policy : canAccess(Req, Res, Act, Env) ← f _Host Authorization(Attr(Req), Attr(Res), Attr(Act), Attr(Env)) ∧ f _IdentityAuthorization(Attr(Req), Attr(Res), Attr(Act), Attr(Env)) The function f_HostAuthorization() and f_ IdentityAuthorization() are defined in the host based authorization policy and identity based authorization policy. In Grid systems, combine_f() of the ABMAC policy also can use following combining algorithms: •

•

Deny override If “deny” is returned by any policy, the final decision will be deny. If no deny is returned, the final decision will be permit. Permit override If “permit” is returned by any policy, the final decision will be permit. If no permit is returned, the final decision will be deny.

3.4 ABMAC and ABAC ABMAC is defined on the base of ABAC. The main differences between the two models are the policy description and policy evaluation methods, as shown in Table 1. Policy description and evaluation are the most important parts in attribute-based access control models. ABMAC defines a hierarchical policy structure basing on the abstraction and encapsulation concepts. The policy of ABMAC is a policy set composed of different types of policies

175

that need to be supported. The policies are encapsulated; that is, they use their own definitions and decision-making algorithms. Compared with ABAC model, ABMAC does not use a unified method to describe multiple policies. A unified description method would force the policies to change their descriptions, a situation that is difficult to achieve and is impractical in a heterogeneous real system. Also, ABMAC need not to build a special evaluation algorithm like ABAC, it can use the decision-making algorithms of the contained policies. When a VO is being established, ABMAC can be built by using existing access control mechanisms in ADs. Hence ABMAC is a policy framework that can describe multiple heterogeneous policies. The encapsulation of the heterogeneous policies enables ABMAC to support multiple policies effectively and makes the model more flexible and scalable.

4 GT4 Attribute-Based Multipolicy Authorization Framework As a fundamental enabling platform for Grid, the authorization mechanism of Globus should have the following properties: • • •

Supporting attribute based access control. Being flexible and scalable for supporting multiple policies. Being open for integrating existing authorization systems.

The Globus Toolkit release 4 (GT4) implements the WSRF specification, which is a convergence of Grid and Web services technology. Several Web services standards are introduced into Grid computing. For building such a flexible authorization system, we use ABMAC as the policy model,

Table 1 The comparison between ABMAC and ABAC Definitions

ABMAC

ABAC

Policy description

A policy is a set composed of different types of policies. Each contained policy is described using its own definition. The policy is evaluated by evaluating each composed policy using the policy’s special decision-making algorithm.

Using a unified policy language to describe any type of policies. The policy is evaluated by analysing or reasoning on the policy description.

Policy evaluation

176

B. Lang et al.

and designed the authorization mechanism using Web services specifications such as XACML and SAML. 4.1 Multipolicy Framework in GT4 The PDP is the entity that implements the policy evaluation function of a policy model. It is the core of the authorization framework that makes access control decisions. In XACML, PDP is supposed to implement only one type of policy that is described using a policy language, and the multipolicy supporting methods are not provided. Based on the concepts described in ABMAC, we define a scalable multipolicy framework, shown in Fig. 2. Each policy, such as Grid map file and access control list, is the policy_i in ABMAC. These policies essentially need their own decision functions that understand the intrinsic semantics of the policy expressions. Hence we encapsulate each policy in an independent PDP. At the same time, we define an abstract PDP that has the common characteristic of the policies. In accordance with the policy ABMAC_Policy in ABMAC, the PDP abstraction (the PDP class in Fig. 2) defines a common evaluation interface canAccess() that can be used to interact with the PEP or with other PDPs. This common interface presents the decision request as a collection of attribute values for the subject, resource, and action. Each specific policy is a subclass of the PDP abstraction, which implements the common interface canAccess() inherited from PDP with its own policy and evaluation mechanism. In the implementation of the policy framework, an authorization engine is created that implements the ABMAC_Policy in ABMAC. The au-

thorization engine first collects information about the request and calls the PDPs, then combines the decisions from all the different PDP instances, and renders a single decision reflecting the overall evaluated policies. Since the policy framework is object oriented, it is scalable and flexible, which means that new policies can be added to the framework just by inheriting the PDP class and the existing policies can be removed and modified at any time. Also, since PDP instances are queried through the same interface and since the mechanism-specific details of the PDPs are all hidden behind the public interface, changes to the policy framework will have no effect on the authorization engine: it can cooperate with any specific PDPs designated by the security configuration files. This multipolicy framework thus provides users of GT4 with an authorization mechanism that is flexible and scalable to support multiple different policies. 4.2 Architecture of GT4 Authorization Framework Based on the GT4 authorization policy framework and on the XACML and SAML standards, we built the GT4 authorization framework, which is shown in Fig. 3. The framework is composed of a PEP, an authorization engine, PDPs, and PIPs. The authorization engine and the PDPs implement the policy of ABMAC, i.e. ABMAC_policy. Grid systems have several frequently used simple authorization policies or mechanisms. We provided multiple PDPs which implement these policies, such as AccessControlListPDP for DAC and GridMapAuthorizaionPDP for Grid map file. Each PDP implements a f_policy_i () in

Fig. 2 GT4 authorization policy framework

PDP CanAccess()

GridMapPDP

SAMLCalloutPDP

IdentityPDP

AccessControlListPDP

CanAccess()

CanAccess()

CanAccess()

CanAccess()

...

A flexible ABAC method for Grid computing

177

Fig. 3 GT4 authorization framework

X509BootstrapPIP Security Confuguration file

SAMLAuthzAssertionPIP PIPs

... ...

GridMapAuthorizaion PDP

Authorization Engine Decision Request

AccessControlList PDP

Decision Result

... ...

PEP Request

SAMLAuthorizationCallout PDP

Client

PDPs Request Grid Service

... ...

SAML Shibboleth

ABMAC_policy() which provides the evaluation of a kind of policy. In order to integrate the authorization systems developed by others into the authorization framework, such as Shibboleth, VOMS and PERMIS, a SAMLAuthorizationCalloutPDP is established that integrates these systems through the SAML assertions. Four types of decision result may be returned by each PDP: permit, deny, not applicable, and indeterminate. The authorization engine implements the combine_f() of ABMAC_policy, which provides a combining algorithm such as Deny override, Permit override, and First applicable to combine the decisions returned by each PDP. The PEP intercepts the user’s request and executes the authorization decision received from the authorization engine. The PIPs are information collection points that collect attributes about various entities defined in

Fig. 4 Attributes collection in GT4

SAML

SAML

PERMIS

ABMAC including the requestor, the resource, the action, and the environment. The attributescollecting process is shown in Fig. 4. When collecting the authorization information, the Container PIP is first invoked to collect attributes inherent to the framework, such as the service name and the operation name. Next, the Bootstrap PIPs are invoked to collect information about the request; usually the X509 Bootstrap PIP is invoked before any other Bootstrap PIP configured. Then, other PIPs are invoked in the configured order. Each PIP might return a normalized representation of the collected attributes. The attributes then are grouped as a single set of attributes per entity and are stored, so that the PDPs in the PDP chain can access them when evaluating their policies. In the authorization framework, the collection of Bootstrap PIPs, PIPs, and PDPs is referred to

Attributes Set Per Entity Container PIP

The PDP Chain

Entity 1

AccessControlList PDP

Entity 2

GridMapAuthorization PDP

Attributes Grouping

Bootstrap PIP

... ...

... ...

Entity 3

... ... PIP List

SAML Authorization Assertion PIP

... ...

... ...

Entity n

SAMLCallout PDP

178

as an authorization chain. An authorization chain can be configured through the security configuration file (shown in Fig. 3) or programmatically at the resource, service, and container level. 4.3 GT4 Authorization Framework Decision-Making Algorithm This section describes the algorithm that the GT4 authorization framework uses to implement the combine_f() function of the ABMAC policy. When a request of the Grid resource comes, it is intercepted by the PEP and sent to the authorization engine to begin evaluation. The evaluation algorithm implemented by the authorization framework is expressed as follows: CALL Authorization_engine_decision() with the request RETURNING decision IF decision = ‘permit’ THEN Forward the request to the Grid resource ELSE Deny the request END IF Authorization_engine _decision(request) Input PIP subchain, PDP subchain CALL BootstrapPIP_attribute_collection() RETURNING attributes of the requestor Add the attributes to the request-attributestorage FOR each PIPi in PIP subchain CALL PIPi _attribute_collection() RETURNING attributesi Add the attributesi to request-attribute-storage ENDFOR Group the attributes in request-attribute-storage into entities Associate the entities with resource, action, and environment. FOR each PDP j in PDP subchain CALL PDP j_canAccess() with the requestor, the resource, the action, the environment RETURNING decision j CALL Authorization_engine _combinaton_ algorithm() with the decision j RETURNING decision IF decision = ‘permit’ or decision = ‘deny’ THEN Break

B. Lang et al.

ENDIF ENDFOR RETURN with decision When the authorization engine received the evaluation request from PEP, it first collects information needed by calling the Bootstrap PIPs and other PIPs and then invokes the corresponding PDPs with the request and the attribute information collected. The PIPs and the PDPs used are all specified in the security configuration file. When the authorization engine receives the decisions returned by each PDP, it combines the decisions, using a policy combination algorithm to render a final decision, and returns the decision to the PEP. The PEP then executes the decision, either denying or permitting the request. 4.4 Integration of Third-Party Authorization Systems As shown in Fig. 3, the GT 4 authorization framework uses a SAMLAuthorizationCallout PDP to integrate a third-party authorization system, such as Shibboleth and PERMIS. The SAML specification defines a number of elements for making assertions and queries regarding authentication, authorization decisions, and attributes [25]. As for authorization, SAML defines messages exchanged between a PEP and a PDP: the AuthorizationDecisionQuery element is used to send request to the PDP, and an Assertion returned from the PDP contains some number of AuthorizationDecisionStatements. Both the SAMLAuthorizationCallout PDP in the GT4 authorization framework and the integrated third-party authorization systems support the GGF OGSI Authorization Service specification, which is based on the use of SAML as a format for requesting and expressing authorization assertions. The SAMLAuthorizationCallout PDP sends a SAML AuthorizationDecisionQuery or ExtendedAuthorizationDecisionQuery to an outside authorization service. The AuthorizationDecisionQuery contains a Subject, Resource, and any number of Action elements. The outside authorization service evaluates the request against its policy and returns a response encoded as

A flexible ABAC method for Grid computing

a SAML Assertion. The Assertion may include an optional Conditions element specifying the conditions for use of the assertion, an optional Advice element specifying advice for use of the element, any number of AuthorizationDecisionsStatements, any number of AttributeStatements in Evidence elements, and an optional Signature element allowing the Assertion to be verified. The SAMLAuthorizationCallout PDP will then analyze the assertion returned. If the assertion contains a positive decision, the request will be permitted; otherwise it will be denied. 4.5 Implementation Results The GT4 authorization framework including PEP, an authorization engine, PDPs, and PIPs has been implemented. The built-in PDPs of the toolkit include: •

• • • •

•

org.globus.wsrf.impl.security.authorization. SelfAuthorization for self authorization policy which means only clients that present the same identity as the identity in the current JAAS(Java Authentication Authorization Service) subject associated with the service are allowed to access the service; org.globus.wsrf.impl.security.authorization. GridMapAuthorization for Grid map file policy; org.globus.wsrf.impl.security.authorization. IdentityAuthorization for identity authorization policy; org.globus.wsrf.impl.security.authorization. HostAuthorization for host based policy; org.globus.wsrf.impl.security.authorization. SAMLAuthorizationCallout for calling out to a configured OGSA-AuthZ compliant authorization service. org.globus.wsrf.impl.security.authorization. UsernameAuthorization for integrating a third party authorization system.

When using the GT4 authorization framework to build the authorization system of a Grid, ADs can use the built-in PDPs, or integrate third party authorization services by the SAMLAuthorizationCallout PDP, even they can build new PDPs and insert into the framework. ADs do so by listing the selected PDPs and related PIPs in

179

the security configuration file. Hence, the GT4 attribute based authorization framework is flexible and scalable for supporting multiple security policies. The GT4 authorization framework was built on the base of XACML and SAML: the authorization architecture of XACML is used and extended to construct the framework architecture, and SAML is used to specify and convey authorization decisions and attributes between the framework and the third party authorization systems. Compared with the XACML authorization architecture, the value added by GT4 authorization framework is the flexibility of supporting multiple policies. By using a uniform policy language, XACML can describe different type of security policies, but the ADs have to change the description and evaluation algorithm of their policies and build a new policy evaluate mechanism, which is complex and impractical under some circumstances. However, in GT4 authorization framework, by using the multipolicy model, each policy remains its description and evaluation mechanism, and also new policies can be plugged in conveniently. This will make ADs in a Grid build or change their authorization mechanism easily and effectively, which is especially important for a Grid system that is dynamically constructed by autonomous domains.

5 Conclusion Attribute-based access control, which making access decisions based on the attributes of requestors, resources, and the environment, provides the flexibility and scalability that are essential to large-scale distributed systems such as the Grid. To support the special authorization requirements of Grid computing, we suggested an attribute-based multipolicy access control model ABMAC and developed the GT4 authorization framework that supports the model. The authorization framework provides the needed features for Grid computing, which makes decisions based on attributes of related entities, supports multiple policies, and can integrate third-party attributebased authorization systems. Our results show

180

that the ABMAC model and the architecture for implementing attribute-based multipolicy access control provided in the GT4 authorization framework are effective. Acknowledgements Work on GT4 GSI has been funded in part by NSF, by IBM, and by the US Department of Energy under Contract W-31-109-Eng-38.

References 1. Lampson, B.W.: Protection. In: Proceedings of the 5th Princeton Conference on Information Sciences and Systems, pp. 437–443. Princeton University, Princeton N.J. (1971) 2. Bell, D.E., LaPadula, L.: Secure computer systems: a mathematical model. Mitre Corporation, Bedford, MA (1973, January) 3. Sandhu, R.S., Samaratiy, P.: Access control: principles and practice. IEEE Commun. 32(9), 40–48 (1994) 4. Foster, I., Kesselman, C., Tuecke, S.: The anatomy of the grid: enabling scalable virtual organizations. Intern. J. Supercomp Appl. 15(3), 200–222 (2001) 5. Lang, B., Foster, I., Siebenlist, F., Ananthakrishnan, R., Freeman, T.: A multipolicy authorization framework for grid security. In: Proceedings of the 5th IEEE International Symposium on Network Computing and Applications, Cambridge, USA (2006, July) 6. ITU-T Recommendation X.509: Information technology—open systems interconnection—the directory: authentication framework, ISO/IEC 9594-8 (1993) 7. Housley, R., Ford, W., Polk, W., Solo, D.: Internet X.509 Public Key Infrastructure Certificate and CRL Profile (1998, September) 8. Park, J.S., Sandhu, R.: RBAC on the web by smart certificates. In: Proceedings of the 4th ACM Workshop on Role-Based Access Control. ACM, Fairfax, VA, October 28–29 (1999) 9. Rivest, R.L., Lampson, B.: SDSI—a simple distributed security infrastructure. Presented at CRYPTO ‘96 Rumpsession (1996, April) 10. Thompson, M., Johnston, W., Mudumbai, S., Hoo, G., Jackson, K., Essiani, A.: Certificate-based access control for widely distributed resources. In: Proceedings of the Usenix Security Symposium, August (1999) 11. Park, J.S., Sandhu, R.: Smart Certificates: Extending X.509 for Secure Attribute Service on the Web. NISSC (1999) 12. Farrell, S., Housley, R.: An Internet attribute certificate profile for authorization. IETF–RFC 3281 (2002) 13. Damiani, E., Vimercati, S.D.C., Samarati, P.: New paradigms for access control in open environments. In:

B. Lang et al.

14.

15.

16.

17.

18.

19. 20.

21.

22.

23.

24. 25. 26.

27.

Proceedings of the 5th IEEE International Symposium on Signal Processing and Information, Athens, Greece, December 18–21 (2005) Bonatti, P., Samarati, P.: A unified framework for regulating access and information release on the web. J. Comput. Secur. 10(3), 241–272 (2002) Wang, L., Wijesekera, D., Jajodia, S.: A logic-based framework for attribute based access control. In: Proceedings of the 2004 ACM Workshop on Formal Methods in Security Engineering, Washington, DC, October (2004) Yuan, E., Tong, J.: Attributed based access control (ABAC) for Web services. In: Proceedings of the IEEE International Conference on Web Services (ICW’05) (2005, July) Squicciarini, A.C., Bertino, E., Goasguen, S.: Access control strategies for virtualized environments in grid computing systems. In: Proceedings of the 11th IEEE International Workshop on Future Trends of Distributed Computing Systems (FTDCS’07) (2007) Thompson, M., Essiari, A., Mudumbai, S.: Certificatebased authorization policy in a PKI environment. ACM Trans. Inform. Syst. Secur. (TISSEC) 6(4), 566– 588 (2003, November) Chadwick, D.: Authorization in grid computing. Inform. Secur. Tech. Rep. 10(1), 33–40 (2005) Chadwick, D., Otenko, A.: The PERMIS X.509 role based privilege management infrastructure. Future Gener. Comput. Systs. 19(2), 277–289 (2003, February) Welch, V., Barton, T., Keahey, K., Siebenlist, F.: Attributes, anonymity, and access: Shibboleth and Globus integration to facilitate grid collaboration. In: 4th Annual PKI R&D Workshop, April (2005) Barton, T., Basney, J., Freeman, T., Scavo, T., Siebenlist, F., Welch, V., Ananthakrishnan, R., Baker, B., Goode, M., Keahey, K.: Identity federation and attribute-based authorization through the globus toolkit, Shibboleth, Gridshib, and MyProxy. In: 5th Annual PKI R&D Workshop, April (2006) Alfteri, R., Cecchini, R., Ciaschini, V., Dellagnello, L., Frohner, A., Gianoli, A., Lorentey, K., Spataro, F.: VOMS, an authorization system for virtual organizations. In: 1st European Across Grids Conference, Santiago de Compostela, February 13–14 (2003) OASIS, Extensible Access Control Markup Language (XACML), V2.0 (February 2005) OASIS, Security Assertion Markup Language (SAML), V2.0 (March 2005) Foster, I., Frey, J., Graham, S., Tuecke, S., Czajkowski, K., Ferguson, D., Leymann, F., Nally, M., Storey, T., Weerawaranna, S.: Modeling stateful resources with Web Services. Globus Alliance (2004) Czajkowski, K., Ferguson, D.F., Foster, I., Frey, J., Graham, S., Sedukhin, I., Snelling, D., Tuecke, S., Vambenepe, W.: The WS-Resource Framework, Version 1.0, March 5 (2004)