Difference between revisions of "Authorisation Service"

Revision as of 15:19, 12 October 2009

This page describes the gCube Authorisation Service. This service, part of the Virtual_Organisation_Management subsystem, aims at protecting gCube resources, as described in the gCube Security Model page.

gCube authorization framework

The main aim of the Authorization framework is to protect gCube resources from unauthorized access and use. This is achieved enforcing authorization on interactions with gCube resources. The authorization framework is based on the gCube VO model described in the gCube Security Model page. In the VO model introduced there, two concepts are used to model access rights to resources: Sharing Rules and Permissions. Sharing rules are used by Resource Administrators to express constraints on resource usage with respect to Virtual Organizations as a whole, while Permissions are used by VO Administrators to further refine access control over resources within the VO itself. Sharing Rules and Permissions are implemented by the Authorization service through the use of policies, as described in the section below.

Authorization policies

In the Authorization framework, policies are used to express Sharing Rules and Permissions ruling resource usage in the gCube infrastructure. Policies are defined by Resource and VO Administrators, and evaluated wherever an authorization decision is needed to access and use a protected resource.

The following diagram show main interfaces and classes related to the policy definition and evaluation.

Policy - gCube policies are defined by realizing the Policy interface. The diagram shows three Policy implementation, whose behaviour is described in the 'Policy Example' section below. Each Policy implementation will provide two methods telling the evaluation engine:

1. if the Policy applies to the current request, and, in case,
2. what is the Response provided by the Policy to the current Request.

In most common cases, answer to these method will be hard-coded in the Policy implementation, but this approach does not prevent the definition of more flexible policies, where the behaviour is provided (or parametrized) at instantiation time, or even later, at evaluation time. Once defined, policies needs to be instantiated. The set of instantiated policies defines, among those that have been defined, which ones must be enforced by the authorization framework in the running infrastructure.

Policy Evaluation Engine - Once a set of Policies have been defined and instantiated, they are evaluated against a request. A Policy Evaluation Engine object is in charge of coordinate this task. The engine asks instantiated policies about which ones are applicable to the current request, and combines responses of applicable policies to get the definitive result. The combination process can be driven by a set of policy combination rules.

PolicyCombinationRule - This interface represent a policy combination rule a Policy Evaluation Engine applies. Two types of combination are shown in the diagram: AndCombinationRule and OrCombinationRule. These combination rules applies to responses returned by authorization policies, and defines if the combined result must be, respectively, the logical AND of decisions obtained, or the logical OR. As well as policies, combinations rules must also be instantiated. Clearly, the instantiation of combination rules is related to the set of policies that have been instantiated.

Request - Each policy evaluation request originates from an activity within the infrastructure. As a consequence, the request will supply the evaluation engine with information about the subject that is undertaking the activity, the activity itself (named operation in the diagram), the resource(s) involved and the context where the activity is being undertaken (named scope in the diagram).

Notes on policy language

Some policy languages are present in scientific literature to manage access to resources [REF: Permis, XACML, EELA]. The adoption of these languages has been carefully evaluated to express gCube policies, but a simpler, even if less expressive, approach has been prioritized over its adoption.

Moreover, the design of the authorization framework does not impose the adoption of a particular policy language. In fact, leaving the authorization decision up to objects implementing the defined policies, allows to decouple the evaluation engine from the policy language itself. This leave the door open to the adoption, if needed, of multiple, different, policy languages. For the XACML language, for instance, a Policy implementation could delegate the authorization decision to an external XACML engine.

Clearly, the implementation of policies by realization of the Policy interface, requires the identification and definition of available policies at development time. This has been judged acceptable, because the way how authorization policies are expressed heavily depends on the service purpose and behaviour. This approach has also another advantage, i.e. to push service developers in taking security into account during the design of their services and libraries.

Policy Examples

This section contains some examples of policies already available in the authorization framework.

Trusted gHN policy

The most common security requirement is the need to protect invocations to a Running Instance, running on a given gHN, from a client outside the gCube infrastructure. This policy, named "Trusted gHN Policy", represents the ground authorization of the infrastructure, preventing access and usage by external (untrusted) entities. This policy is applied to every gHN that is part of the infrastructure. This policy relies on the set of trusted gHN to be distributed ot each gHN of the infrastructure.

Authorized Identity policy

A further security need is to protect the deployment functionality provided on each gHN by Running Instances of the Deployer service. This policy, named "Authorized Identity policy", relies on the assumption that the VREManager running instance, the only entity allowed to invoke the deployment operation, runs in the infrastructure using its own identity, it could be the identity of the hosting gHN, if the VREManager is the only service deployed in that gHN. The "Authorized Identity policy" will grant access to a Running Instance (the local Deployer in our case) to a given identity only (the VRE Manager identity, in our case). This policy relies on the VREManager identity to be distributed to each gHN, and can be parametrized with the service to be protected, i.e. the Deployer in the case described.

Free Operation policy

The "Free Operation policy" allows everyone, even not from a trusted gHN, to invoke a given operation on a RI. This policy is used to leave the register operation of the IS open to new (untrusted) gHNs. This is needed to enable the automatic registration of new, maybe untrusted, gHN in the infrastructure. Of course, the add of those gHN to the trusted network will require some manual, or automated, approval. This policy needs to be parametrized with the operation to be left open to untrusted clients.

Combining policies

The results of the three policies described above must be properly combined to obtain consistent authorization decisions at policy evaluation time. In particular, when a request is received from a trusted gHN, the logical OR between the "Trusted gHN policy" and the "Free Operation policy" must be enforced. In addition, if the request is targeted to a Deployer service, the "Authorized Identity policy" must be enforced (in and with the previous result). As a consequence, the OrCombinationRule is used to combine the "Trusted gHN policy" and the "Free Operation policy" results on the IS's register operation, while the AndCombinationRule is used to combine the previous result with the "Authorized Identity policy" for the Deployer's deploy operation.

Authorization components

Two components have been defined to implement the authorization framework above: Resource Administration Service (RAS), and VO Administration Service (VOAS).

VO Administration Service

At least one instance of this component must be present in the infrastructure. This component is in charge of:

• harvesting and maintain Policies and policy-related information.
• distribute updates about policies and policy-related information to subscribed RAS instances

The following diagram show how VOAS and RAS interact when a new trusted gHN is added to the infrastructure.

When a new gHNx register itself in the infrastructure, the notification of its registration is sent to the VOAS. The gHNx is then added to the trusted network, and this modification is notified to subscribed RAS instances. Once the gHNx is trusted, its local RAS can subscribe to the VOAS to receive notifications about current policies and related information.

Resource Administration Service

A RI of the RAS service is deployed on each gHN and is in charge to:

• Receive notifications of authorization policies and related information from the VOAS
• Evaluate current policies to return authorization decisions to local services

At startup, each RAS subscrie to the VOAS service to receive notifications about current policies and policy-related information.

The following sequence diagram show how the invocation of a Running Instance is protected by the local RAS.

In the previous diagram the request from the client is mediated by the gHNx libraries that are in charge to add the cryptographic material for client authentication. The request is received by the gHNy where the target service is running, and an evaluation of current policies is issued to the local RAS. The RAS evaluates the set of policies currently in use, and return an authorization decision to the local gHN libraries. The answer to this request defines the behaviour of the gHNy in accepting or denying the current request.