Difference between revisions of "GCube Security Model"

From Gcube Wiki
Jump to: navigation, search
(→‎Components)
 
(36 intermediate revisions by one other user not shown)
Line 1: Line 1:
−
This page describes the overall security model of gCube. Firstly, the authentication handling is introduced, briefly describing the model and components used by gCube to verify user's identity. Secondly, the authorization section gives a brief description of the gCube model, also highlighting main services and components in charge to maintain and enforce authorization policies.
+
This page describes the overall security model of gCube. Firstly, the authentication handling is introduced, briefly describing the model and components used by gCube to verify user's identity. Secondly, the authorization section gives a brief description of how the access control is managed in gCube, also introducing main services and components in charge to maintain and enforce authorization policies.
  
 
==Authentication==
 
==Authentication==
Line 5: Line 5:
 
"Authentication is the act of establishing or confirming something (or someone) as authentic, that is, that claims made by or about the subject are true. This might involve confirming the identity of a person, the origins of an artifact, or assuring that a computer program is a trusted one."<ref name="WIKI_AUTHN">http://en.wikipedia.org/wiki/Authentication</ref>
 
"Authentication is the act of establishing or confirming something (or someone) as authentic, that is, that claims made by or about the subject are true. This might involve confirming the identity of a person, the origins of an artifact, or assuring that a computer program is a trusted one."<ref name="WIKI_AUTHN">http://en.wikipedia.org/wiki/Authentication</ref>
  
−
Being gCube a distributed system, the authentication process mainly focuses on proving the identity of communicating entities (users, services, hosts, etc.). The aim of gCube authentication is mainly to prevent system usage or damaging by malcious entities.
+
Being gCube a distributed system, the authentication process mainly focuses on verifying the identity of communicating entities, i.e. users (through the gCube portal), and Running Instances. This is achieved through the use of authentication tokens, i.e. piece of information, that are exchanged between communicating entities to prove their mutual identity.  
  
 
'''Delegation'''
 
'''Delegation'''
  
−
"In numerous applications it is sometimes necessary to "become" some one else, or some other principal in order to take advantage of some privilege(s) they have. Unix systems have had this concept for decades in the su command. With the advent of web based enterprise applications it became clear that something similar was needed for them. That is it became necessary to be able to pass around a set of privileges in some manner. Since privileges are normally associated with a principal (very often a person) the problem became a question of how to pass around these principal's identities and how to allow one system to use that identity to gain access to information on another system."<ref name="DELEGATION">http://middleware.internet2.edu/webiso/docs/draft-lajoie-trust_and_delegation-02.html</ref>
+
In short, delegation is the process of letting a system entity, typically a service or an application, to act on behalf of another one, e.g a user. This is normally needed in distributed N-Tier multi-domain applications to take (limited) advantage of privileges grant to the original entity, without the need to directly assign them to the delegated entity<ref name="DELEGATION">http://middleware.internet2.edu/webiso/docs/draft-lajoie-trust_and_delegation-02.html</ref>. Therefore, identity delegation in gCube refers to the process of allowing system services and resources to act on user's behalf. An important point concerning delegation is that, in gCube, services can be dynamically deployed, and autonomously operate in the infrastructure. This implies that a delegation mechanism of user's credentials is required by those services that act in the infrastructure on the user's behalf.  
−
 
+
−
As from the previous excerpt, identity delegation in gCube is the process of allowing system services and resources to act on user's behalf. This functionality is often required in N-tier large-scale systems, like gCube. An important point to be taken into account when considering delegation is that gCube service can be dynamically deployed in the infrastructure, even if the service administator is not logged in. Even in those cases, valid credentials must be delegated to the deployed service in order to properly operate in the gCube infrastructure.
+
  
 
===Model===
 
===Model===
  
−
gCube architecture exploits the Public Key Infrastructure<ref name="PKI">http://en.wikipedia.org/wiki/Public_key_infrastructure</ref> (PKI) paradigm to uniquely identify users in the infrastructure. gCube users are then provided with a set of credentials, i.e. a private key and a public certificate, that are used to for authentication to other entities. Credentials are typically issued and revoked to users by a trusted entity, named Certification Authority (CA). The gCube infrastructure is designed to support CAs acknowledged by the International Grid Trust Federation<ref name="IGTF">http://www.igtf.net/</ref> (IGTF) as well as an infrastructure-specific CA, named "D4Science CA" in the following of this section.
+
gCube architecture exploits the '''Public Key Infrastructure'''<ref name="PKI">http://en.wikipedia.org/wiki/Public_key_infrastructure</ref> (PKI) to uniquely identify users and services in the infrastructure. gCube users and services are provided with an authentication token, named credentials, i.e. a private key and a public certificate, that are used to authenticate them to other entities. In PKI, credentials are issued and revoked to users by a trusted entity, named Certification Authority (CA). The gCube infrastructure is designed to support CAs acknowledged by the International Grid Trust Federation<ref name="IGTF">http://www.igtf.net/</ref> (IGTF) as well as an infrastructure-specific CA, named "D4Science CA" in the following.
  
−
As from the previous, each interaction between entitites, e.g. a service invocation, should be performed in gCube using valid credentials, issued by a trusted Certification Authority (CA).  
+
As from the previous, each interaction between gCube Running Instances, e.g. a service invocation, should be performed in gCube using valid credentials, issued by a trusted Certification Authority (CA).  
  
−
As far as performances are concerned, security does not come for free. Sometimes the overhead introduced in service invocation by the security handshake can take much longer than the invocation itself, thus excessively penalizing service usability. For this reason also unauthenticated invocatons among gCube entities have been allowed, in those cases wherever the cost of security was judged too high with respect to advantages introduced. Unauthenticated invocations can be performed without any credentials, neither authentication nor authorization are enforced in these cases.
+
As a consequence of this every authenticated communication between gCube entities is performed using valid credentials, issued by a trusted Certification Authority (CA). The main protocol adopted by gCube for secure communications is the '''HTTPS'''<ref name="HTTPS">http://en.wikipedia.org/wiki/HTTP_Secure</ref>: however the ''WS-SecureConversation''<ref name="WS_SEC_CONV">http://specs.xmlsoap.org/ws/2005/02/sc/WS-SecureConversation.pdf</ref>, previously adopted, is still available. The choice of the HTTPS mechanism to protect gCube interactions is mainly due to the better performances provided by HTTPS with respect to message-level security mechanisms. If we use https as only authentication protocol, we will not be able to use the standard delegation mechanism.
 +
 
 +
Nevertheless, even considering HTTPS performances, security does not come for free. Sometimes, the overhead introduced in service invocation by the security handshake can take much longer than the invocation itself, thus excessively penalizing the service usability. For this reason, wherever the cost of security was judged too high with respect to advantages introduced, unauthenticated invocations among gCube entities have been allowed also. In those cases, as unauthenticated invocations are performed without valid credentials, neither authentication nor authorization are enforced.
 +
 
 +
'''Trusted network'''
 +
 
 +
We define as Trusted Network a ''Network of trusted GHN'', where trusted means that their host certificates are signed by a Certification Authority belonging to a specific set. Inside the network the authentication process is simpler. If a call comes from the trusted network (i.e. it is signed by a trusted host certificate), it is considered authenticated: if the specific caller identity is needed (even for delegation purposes), it is provided by roles information used for the authorization process.
  
−
The definition of gCube user not only includes human users, but also services autonomously acting in the system. Batch services (e.g. monitoring services) are an example of such users that, reacting to status changes, or on a temporal basis, interact with other system entities. Thus, some gCube services need to be identified and managed, from the authentication and authorization point of view, as users.
 
  
 
===Components===
 
===Components===
 +
Inside the trusted infrastructure there is no need of any specific component, only two features must be present:
  
−
The mechanism currently used in gCube to authenticate service invocatons is the WS-SecureConversation <ref name="WS_SEC_CONV">http://specs.xmlsoap.org/ws/2005/02/sc/WS-SecureConversation.pdf</ref> one. The Java WS-Core container provides a built-in implementation of this standard called GSI-SecureConversation. This choice is mainly driven by the need to delegate caller credentials to the invoked service, as described above.
+
* the trusted infrastructure CA (or CAs) certificate in the truststore of every GHN
 +
* an host certificate signed by (one of) the trusted infrastructure CA.
  
−
Credentials in the gCube infrastructure are managed by the following set of components:
+
 
−
*'''MyProxy''' - the MyProxy<ref name="MYPROXY">http://grid.ncsa.uiuc.edu/myproxy/</ref> service is in charge of maintaining a delegated short-term copy of user's credentials. The gCube MyProxy configuration allows for storing both credentials issued by IGTF CAs, both for credentials issued by the D4Science CA. In this second case short-lived credentials are generated on the fly for the user, using the MyProxy online CA functionality<ref name="MYPROXY_CA">http://grid.ncsa.uiuc.edu/myproxy/ca/</ref>.
+
However a '''Delegation''' and a '''CredentialRenewal''' services are provided when classic delegation is needed. The Delegation service provides gCube services with valid credentials to authenticate themselves in the infrastructure. The provisioning of credentials to services operated by the Delegation depends on service security configuration, being the use of container credentials the most common, and simple, case. For services requiring to act on the user behalf, the Delegation interacts with the Credentials Renewal service to retrieve delegated user's credentials. The delegation of user's credentials to a service is subject to a defined set of delegation policies.
−
*Delegation and CredentialRenewal - Delegation and CredentialRenewal services are in charge to provide gCube services with valid credentials to authenticate theirself in the infrastructure. In fact gCube autonomic behaviour, like that of monitoring processes, and the gCube dynamic deployment functionalities requires credentials to be delegated to services even when the user is offline. This is achieved through the Delegation and CredentialRenewal services, and controlled by a set of predefined delegation policies. For a detailed description of these services you can refer to the [[Virtual Organisation Management]] page.
+
 
 +
A more detailed description of the structure and behaviour of the authentication-related components can be found in the [[Virtual Organisation Management]] page.
  
 
==Authorization ==
 
==Authorization ==
−
"Authorization is the function of specifying access rights to resources, which is related to information security and computer security in general and to access control in particular. More formally, "to authorize" is to define access policy. For example, HR staff are normally authorized to access employee records, and this policy is usually formalized as access control rules in a computer system. During operation, the system uses the access control rules to decide whether access requests from (authenticated) consumers shall be granted or rejected."<ref name="WIKI_AUTHZ">http://en.wikipedia.org/wiki/Authorization</ref>.
 
  
−
Authorization rights in gCube are modeled basing on the RBAC<ref name="RBAC">http://en.wikipedia.org/wiki/Role-Based_Access_Control</ref> model. In such a model each user must held a role to operate in the gCube infrastructure. In particular authorization policies in the system are defined with respect to roles, that, in turn, are assigned to users. Each resource is then in charge to enforce authorization policies on incoming requests.
+
"Authorization is the function of specifying access rights to resources, which is related to information security and computer security in general and to access control in particular. More formally, "to authorize" is to define access policy. For example, Human Resources staff are normally authorized to access employee records, and this policy is usually formalized as access control rules in a computer system. During operation, the system uses the access control rules to decide whether access requests from (authenticated) consumers shall be granted or rejected."<ref name="WIKI_AUTHZ">http://en.wikipedia.org/wiki/Authorization</ref>.
  
−
In distributed multidomain systems the concept of VO is the base to create virtual environments spanning across different administrative domains<ref name="VO_REPORT">http://www.ci.uchicago.edu/events/VirtOrg2008/VO_report.pdf</ref>. gCube architecture mainly aims at enabling Virtual Research Environments, and for this reason Virtual Organizations are a core concept of GCube. In particular, when it comes to authorization, the RBAC model must be merged to the sharing of resources typically enabled by VOs.
+
Authorization rights in gCube are based upon the '''Role Based Access Control'''<ref name="RBAC">http://en.wikipedia.org/wiki/Role-Based_Access_Control</ref>(RBAC) model. In RBAC, each identity is associated to one or more attributes, named roles, that are, in turn, linked to permissions granted to the role itself. This allows for a more flexible management of permissions, with respect to mandatory access control (MAC) and discretionary access control (DAC), that directly link permissions to identities.
 +
 
 +
As a consequence, gCube users must held a role to operate in the gCube infrastructure. In particular authorization policies in the system are defined with respect to roles, that, in turn, are assigned to users. Each resource is then in charge to enforce authorization policies on incoming requests.
 +
 
 +
In distributed, multi-domain systems the term '''Virtual Organisation''' (VO) refers to virtual environments spanning across different administrative domains<ref name="VO_REPORT">http://www.ci.uchicago.edu/events/VirtOrg2008/VO_report.pdf</ref>. gCube architecture mainly aims at enabling Virtual Research Environments, and for this reason Virtual Organizations are a core concept of GCube. In particular, when it comes to authorization, the RBAC model must be merged to the sharing of resources typically enabled in the context of a VO.
  
 
===Model===
 
===Model===
−
Policies granting access to resources complies with the following gCube VO authorization model. In particular authorisation policies are scope specific, being the scope defined as from the gCube reference model  
+
The definition and management of access policies for gCube resources is a process involving two main actors:
−
<ref name="GCUBE_REF_MODEL">https://technical.wiki.d4science.research-infrastructures.eu/documentation/index.php/Reference_Model</ref>. It is worth noticing that the scope introduced in the gCube reference model corresponds to the VO element in the following model.
+
 
 +
* '''Resource Administrators''': these actors are the owners of resources. They have the ultimate control over resource usage. They defines Sharing Rules, ruling the usage of their resources over Virtual Organization.
 +
* '''VO Administrators''': these actors are in charge of define Permissions, describing how a resource, made available to the VO by a Resource Administrator, can be used by Users.
 +
 
 +
The following diagram shows main elements of the VO authorisation model of gCube. In particular, authorisation policies in gCube are scope specific, being the scope concept defined in the [[Reference_Model|gCube reference model]]. It is worth noticing that each scope of the gCube reference model corresponds to a Virtual Organisation in the following model.
 +
 
 +
 
 +
 
 +
 
 +
<center>[[Image:VO_Model.jpg|500px]]</center>
  
  
−
<center>[[Image:VO_Model.jpg]]</center>
 
  
  
 
Each element in the diagram is briefly introduced below:
 
Each element in the diagram is briefly introduced below:
−
* '''VO''': Each VO in the hierarchy represent a context in which authorization rights can be defined and must be evaluated (Scope). Users and Resources can be included in multiple VOs. Sharing rules can be defined by Resource Managers w.r.t. entire VOs.
+
* '''VO''': Each VO in the hierarchy represent a context in which authorization policies are defined and evaluated.
−
* '''User''': Users of the gCube system. This definition includes every service and agent able to autonomously act in the infrastructure. Every user will be univocally identified using a set of user credentials as described in the previous Authentication section.
+
* '''User''': Users of the gCube system. Every user will be univocally identified using a set of user credentials as described in the Authentication section above. Users can be part of more than one VO.
−
* '''Resource''': This element represents all gCube resources. Each resource is identified through a resource id. Resources have to belong to a resource type.
+
* '''Resource''': This element represents the set of gCube resources. Each resource is identified through a resource id, unique in the gCube infrastructure. Resources can be included in more than one VO.
−
* '''ResourceType''': Resource types divides resources in different partitions. Each Resource type is associated to a set of logical operations. These operations can be performed over resources of that type.
+
* '''Operation''': Operations represents actions that can be performed on resources. Each operation is identified by an id that is unique among those of operations available on resources of a given class.
−
* '''Operation''': These are logical operations supported by resources of a given type. Sharing rules and Permissions can be defined using these operations.
+
* '''Sharing Rule''': These policies are defined by Resource Administrators to grant a VO access to a given resource. Sharing rules applies to VO as a whole.
−
* '''Sharing Rule''': Resource Managers can grant VO members access to a given resource defining sharing rules. Sharing rules applies to entire VO, while Permissions applies to roles in a specific VO.
+
* '''Permission''': Permissions are defined by VO Administrators to grant the right to perform operations, described by Sharing Rules, to users with a specific role in the VO. Worth noticing that Permissions are defined starting to Sharing Rules and cannot be less restrictive of Sharing Rules they derives from.
−
* '''Permission''': Permissions can be defined by VO Managers to grant the right to perform operations to a given role.
+
* '''Role''': Roles are associated to users in order to grant them the associated set of permissions. Roles in the gCube authorisation model are associated to users in the context of a given scope.
−
* '''Role''': Roles are associated to users in order to give them permissions to execute a set of operations. Role are hierarchical, child roles inherit permissions of parent roles. Hierarchy allows multiple inheritance. Inheritance relationship among roles can be defined only at role creation.
+
  
−
Policy enforcement requires resources to contact authorization components, described below, to verify if incoming requests complies with the set of defined policies. The push authorization model is used to enforce authorization for gCube resources<ref name="AUTHZ_MODELS">http://www.ogf.org/documents/GFD.38.pdf</ref>. In such a model a piece of information containing the role assignment, and signed by a trusted identity, is embedded in the client certificate, and send to the service during authentication[<ref name="ATTRIB_CERT">http://www.ietf.org/rfc/rfc3281.txt</ref>]. Resources can thus extract user roles from the received certificate and, knowing the resource id, the scope, and the operation invoked, contact the authorization components to get an authorization decision.
+
Policy enforcement is performed by resources contacting  the authorization components, described below, and verifying that the operation asked by the client complies with the set of defined policies (Sharing Rules and Permissions). The '''push authorization model''' is used to enforce authorization for gCube resources<ref name="AUTHZ_MODELS">http://www.ogf.org/documents/GFD.38.pdf</ref>. In our trusted network a piece of information containing the role is added by the Trusted Node. The receiver Node extracts that piece of information and checks if the caller role is authorized to perform the required action. This operation is performed with the aid of the ''Authorization Service''
  
 
===Components===
 
===Components===
−
Following main elements are part of the gCube authorization architecture:
 
  
−
* '''VOMS''' - A VOMS<ref name="VOMS">http://grid-auth.infn.it/</ref> server maintains the scope hierarchy as a VOMS groups hierarchy. It is also in charge to store the set of gCube users, as well as their group membership and roles assigned to them. This component is also in charge to sign
+
In the trusted network Authorization Control is performed by a particular element of the architecture: the '''Authorization Service'''. It is composed by two modules:
−
* '''Resource Authorization Service''' - This service is in charge to store authorization policies for gCube resources, i.e. which roles are needed in a given VO to perform an operation on a resource. This component is also in charge of issuing authorization decisions, whenever asked by resources itself. Multiple instances of the authorization service are usually deployed in the infrastructure to avoid bottleneck in policy evaluation.
+
 
 +
* '''Policy Administration Point''' ('''PAP'''), in which policies, written in a particular syntax, are stored
 +
* '''Policy Decision Pount''' ('''PDP'''), which computes the policies against a certain request and communicates a result, that could be a ''Permit'', a ''Deny'' or an ''Indeterminate''.
 +
 
 +
A third component, the '''Policy Enforcement Point''' ('''PEP''') is represented by the Node that is responsible to apply the decision of the associated PDP. In case of Indeterminate decision the PEP denies the request.
 +
 
 +
The '''VOMS''' is used only for gLite interoperability purpose. In gCube, a VOMS<ref name="VOMS">http://grid-auth.infn.it/</ref> server maintains the scope hierarchy as a groups hierarchy in a dedicated VOMS VO. It is also in charge to store the set of gCube users, as well as their group membership and roles assigned to them. Finally, VOMS is in charge to release signed Attribute Certificates stating user privileges (group membership and roles held).  
  
−
A typical usage scenario for GCube, involving authentication and authorization functionalities is shown in the following diagram.
+
A more detailed description of the structure and behaviour of the authorization-related components can be found in the [[Virtual Organisation Management]] page.
  
−
<center>[[image:Credentials_Management_Overview.jpg]]</center>
+
== References ==
  
−
# When the user logs in the portal, credentials associated with her username/password are retrieved from the MyProxy repository.
+
<references/>
−
# The user is then asked to select the VRE where she wants to operate. The selction triggers the enrichment of user credentials with an attribute certificate signed by the VOMS server. The attribute certificate contains roles held by the user in the current VRE. The credentials obtained are stored in the user session. The user can always change the VRE selection later on; in this case fresh credentials will be generated for the newly selected VRE.
+
−
# During the user session, a number of service invocations happens from the portal to backend services. These invocations are performed with user credentials, enriched with user roles, created in the previous step. On the gCube service side the invocation is authenticated, validating user credentials, and authorized, contacting the Resource Authorization Service. Wherever required, user credentials could also be delegated to backend services; this is achieved using the GSI Conversation Delegation functionality.
+
  
 
[[Category:Security]]
 
[[Category:Security]]

Latest revision as of 14:19, 14 July 2011

This page describes the overall security model of gCube. Firstly, the authentication handling is introduced, briefly describing the model and components used by gCube to verify user's identity. Secondly, the authorization section gives a brief description of how the access control is managed in gCube, also introducing main services and components in charge to maintain and enforce authorization policies.

Authentication

"Authentication is the act of establishing or confirming something (or someone) as authentic, that is, that claims made by or about the subject are true. This might involve confirming the identity of a person, the origins of an artifact, or assuring that a computer program is a trusted one."[1]

Being gCube a distributed system, the authentication process mainly focuses on verifying the identity of communicating entities, i.e. users (through the gCube portal), and Running Instances. This is achieved through the use of authentication tokens, i.e. piece of information, that are exchanged between communicating entities to prove their mutual identity.

Delegation

In short, delegation is the process of letting a system entity, typically a service or an application, to act on behalf of another one, e.g a user. This is normally needed in distributed N-Tier multi-domain applications to take (limited) advantage of privileges grant to the original entity, without the need to directly assign them to the delegated entity[2]. Therefore, identity delegation in gCube refers to the process of allowing system services and resources to act on user's behalf. An important point concerning delegation is that, in gCube, services can be dynamically deployed, and autonomously operate in the infrastructure. This implies that a delegation mechanism of user's credentials is required by those services that act in the infrastructure on the user's behalf.

Model

gCube architecture exploits the Public Key Infrastructure[3] (PKI) to uniquely identify users and services in the infrastructure. gCube users and services are provided with an authentication token, named credentials, i.e. a private key and a public certificate, that are used to authenticate them to other entities. In PKI, credentials are issued and revoked to users by a trusted entity, named Certification Authority (CA). The gCube infrastructure is designed to support CAs acknowledged by the International Grid Trust Federation[4] (IGTF) as well as an infrastructure-specific CA, named "D4Science CA" in the following.

As from the previous, each interaction between gCube Running Instances, e.g. a service invocation, should be performed in gCube using valid credentials, issued by a trusted Certification Authority (CA).

As a consequence of this every authenticated communication between gCube entities is performed using valid credentials, issued by a trusted Certification Authority (CA). The main protocol adopted by gCube for secure communications is the HTTPS[5]: however the WS-SecureConversation[6], previously adopted, is still available. The choice of the HTTPS mechanism to protect gCube interactions is mainly due to the better performances provided by HTTPS with respect to message-level security mechanisms. If we use https as only authentication protocol, we will not be able to use the standard delegation mechanism.

Nevertheless, even considering HTTPS performances, security does not come for free. Sometimes, the overhead introduced in service invocation by the security handshake can take much longer than the invocation itself, thus excessively penalizing the service usability. For this reason, wherever the cost of security was judged too high with respect to advantages introduced, unauthenticated invocations among gCube entities have been allowed also. In those cases, as unauthenticated invocations are performed without valid credentials, neither authentication nor authorization are enforced.

Trusted network

We define as Trusted Network a Network of trusted GHN, where trusted means that their host certificates are signed by a Certification Authority belonging to a specific set. Inside the network the authentication process is simpler. If a call comes from the trusted network (i.e. it is signed by a trusted host certificate), it is considered authenticated: if the specific caller identity is needed (even for delegation purposes), it is provided by roles information used for the authorization process.


Components

Inside the trusted infrastructure there is no need of any specific component, only two features must be present:

  • the trusted infrastructure CA (or CAs) certificate in the truststore of every GHN
  • an host certificate signed by (one of) the trusted infrastructure CA.


However a Delegation and a CredentialRenewal services are provided when classic delegation is needed. The Delegation service provides gCube services with valid credentials to authenticate themselves in the infrastructure. The provisioning of credentials to services operated by the Delegation depends on service security configuration, being the use of container credentials the most common, and simple, case. For services requiring to act on the user behalf, the Delegation interacts with the Credentials Renewal service to retrieve delegated user's credentials. The delegation of user's credentials to a service is subject to a defined set of delegation policies.

A more detailed description of the structure and behaviour of the authentication-related components can be found in the Virtual Organisation Management page.

Authorization

"Authorization is the function of specifying access rights to resources, which is related to information security and computer security in general and to access control in particular. More formally, "to authorize" is to define access policy. For example, Human Resources staff are normally authorized to access employee records, and this policy is usually formalized as access control rules in a computer system. During operation, the system uses the access control rules to decide whether access requests from (authenticated) consumers shall be granted or rejected."[7].

Authorization rights in gCube are based upon the Role Based Access Control[8](RBAC) model. In RBAC, each identity is associated to one or more attributes, named roles, that are, in turn, linked to permissions granted to the role itself. This allows for a more flexible management of permissions, with respect to mandatory access control (MAC) and discretionary access control (DAC), that directly link permissions to identities.

As a consequence, gCube users must held a role to operate in the gCube infrastructure. In particular authorization policies in the system are defined with respect to roles, that, in turn, are assigned to users. Each resource is then in charge to enforce authorization policies on incoming requests.

In distributed, multi-domain systems the term Virtual Organisation (VO) refers to virtual environments spanning across different administrative domains[9]. gCube architecture mainly aims at enabling Virtual Research Environments, and for this reason Virtual Organizations are a core concept of GCube. In particular, when it comes to authorization, the RBAC model must be merged to the sharing of resources typically enabled in the context of a VO.

Model

The definition and management of access policies for gCube resources is a process involving two main actors:

  • Resource Administrators: these actors are the owners of resources. They have the ultimate control over resource usage. They defines Sharing Rules, ruling the usage of their resources over Virtual Organization.
  • VO Administrators: these actors are in charge of define Permissions, describing how a resource, made available to the VO by a Resource Administrator, can be used by Users.

The following diagram shows main elements of the VO authorisation model of gCube. In particular, authorisation policies in gCube are scope specific, being the scope concept defined in the gCube reference model. It is worth noticing that each scope of the gCube reference model corresponds to a Virtual Organisation in the following model.



VO Model.jpg



Each element in the diagram is briefly introduced below:

  • VO: Each VO in the hierarchy represent a context in which authorization policies are defined and evaluated.
  • User: Users of the gCube system. Every user will be univocally identified using a set of user credentials as described in the Authentication section above. Users can be part of more than one VO.
  • Resource: This element represents the set of gCube resources. Each resource is identified through a resource id, unique in the gCube infrastructure. Resources can be included in more than one VO.
  • Operation: Operations represents actions that can be performed on resources. Each operation is identified by an id that is unique among those of operations available on resources of a given class.
  • Sharing Rule: These policies are defined by Resource Administrators to grant a VO access to a given resource. Sharing rules applies to VO as a whole.
  • Permission: Permissions are defined by VO Administrators to grant the right to perform operations, described by Sharing Rules, to users with a specific role in the VO. Worth noticing that Permissions are defined starting to Sharing Rules and cannot be less restrictive of Sharing Rules they derives from.
  • Role: Roles are associated to users in order to grant them the associated set of permissions. Roles in the gCube authorisation model are associated to users in the context of a given scope.

Policy enforcement is performed by resources contacting the authorization components, described below, and verifying that the operation asked by the client complies with the set of defined policies (Sharing Rules and Permissions). The push authorization model is used to enforce authorization for gCube resources[10]. In our trusted network a piece of information containing the role is added by the Trusted Node. The receiver Node extracts that piece of information and checks if the caller role is authorized to perform the required action. This operation is performed with the aid of the Authorization Service

Components

In the trusted network Authorization Control is performed by a particular element of the architecture: the Authorization Service. It is composed by two modules:

  • Policy Administration Point (PAP), in which policies, written in a particular syntax, are stored
  • Policy Decision Pount (PDP), which computes the policies against a certain request and communicates a result, that could be a Permit, a Deny or an Indeterminate.

A third component, the Policy Enforcement Point (PEP) is represented by the Node that is responsible to apply the decision of the associated PDP. In case of Indeterminate decision the PEP denies the request.

The VOMS is used only for gLite interoperability purpose. In gCube, a VOMS[11] server maintains the scope hierarchy as a groups hierarchy in a dedicated VOMS VO. It is also in charge to store the set of gCube users, as well as their group membership and roles assigned to them. Finally, VOMS is in charge to release signed Attribute Certificates stating user privileges (group membership and roles held).

A more detailed description of the structure and behaviour of the authorization-related components can be found in the Virtual Organisation Management page.

References

  1. ↑ http://en.wikipedia.org/wiki/Authentication
  2. ↑ http://middleware.internet2.edu/webiso/docs/draft-lajoie-trust_and_delegation-02.html
  3. ↑ http://en.wikipedia.org/wiki/Public_key_infrastructure
  4. ↑ http://www.igtf.net/
  5. ↑ http://en.wikipedia.org/wiki/HTTP_Secure
  6. ↑ http://specs.xmlsoap.org/ws/2005/02/sc/WS-SecureConversation.pdf
  7. ↑ http://en.wikipedia.org/wiki/Authorization
  8. ↑ http://en.wikipedia.org/wiki/Role-Based_Access_Control
  9. ↑ http://www.ci.uchicago.edu/events/VirtOrg2008/VO_report.pdf
  10. ↑ http://www.ogf.org/documents/GFD.38.pdf
  11. ↑ http://grid-auth.infn.it/
Retrieved from "https://wiki.gcube-system.org/index.php?title=GCube_Security_Model&oldid=12166"