Difference between revisions of "Virtual Organisation Management"

From Gcube Wiki
Jump to: navigation, search
 
(35 intermediate revisions by 5 users not shown)
Line 1: Line 1:
== Virtual Organisation Management ==
+
<!-- CATEGORIES -->
The Virtual Organisation Management (VO-Management) services are in charge to supply other gCube services with a robust and flexible security framework and to manage the VO. The Delegation and CredentialsRenewal services provide authentication support for gCube users and services.
+
[[Category: Developer's Guide]]
The Authorization service is in charge to manage permissions to perform action within the infrastructure.
+
<!-- CATEGORIES -->
  
=== Authentication model ===
+
The Virtual Organisation Management (VO-Management) subsystem provides gCube security-related components. It is part of the [[GCube Infrastructure Enabling Services]], and its main aim is to enable the controlled sharing of gCube resources within a gCube infrastructure. The components implement '''Security As A Service''' Model (''Secaas'') and are based on ''Service Oriented Authorization, Authentication and Accounting'' (SOA3) framework.
The gCube Security model is based on PKI paradigm to authenticate entities identities acting in the infrastructure. This implies that each action must be performed using valid credentials issued by a trusted Certification Authority (CA). The GSI-Secure Conversation standard built-in in the java-WS-Core container is used in gCube to authenticate RI invocations. In fact, there is the need to address every interaction with the system to a particular entity (user or service). For this reason all entities should have its own identity. In certain cases, services could act on behalf of a human user: GSI-SecureConversation can support credentials delegation. This choice is driven, above all, by the need to delegate caller credentials to the invoked RI.
+
  
=== Authorization model ===
+
GCube security model is based on the ''application of security policies for limiting the accessing to services''. Basing on this statement, the main entities characterising the security domain are the following:
The Authorization rights in gCube are based on the RBAC model. This means that each user needs to hold a valid role to operate in a gCube-based infrastructure. The following diagram shows how the gCube VO model is implemented.
+
* '''Actors''', i.e. the ''subjects'' to be authenticated and authorized. In the most of cases they are the ''human users'' registered on IMarine Portal or on Federated domains. In other cases the ''subjects'' are services that have to perform some batch operations by using any associated identity: in these cases the credentials are X509 Certificates and the authorization policies are based on the attributes of associated service profiles
 +
* '''Actions''', i.e. the ''operations'' that the ''subjects'' can or cannot perform. In IMarine context they are ''service categories'', defined by service name and service class: this means that groups of users (or services) can be authorized to use some ''service categories'' 
 +
* '''Resources''', i.e. the ''objects'' of authorization queries, in other words on ''what'' the ''subject'' can or cannot perform the ''operation''. In IMarine context ''resources'' are ''service instances'', i.e. the actual deployment of the service on a certain node. A service instance is identified by the attributes of the Node on which it is deployed.
 +
* '''Policies''', i.e. the statements defining which ''service instances'' a certain ''subject'' can use.
  
[[Image:Vo.jpg]]
+
The detailed description of the subsystem is on [[Data e-Infrastructure Policy-oriented Security Facilities]] page, where the links to the main functionalities
  
== Reference Architecture ==
+
* [[SOA3_Authentication_Module|Authentication]]
VO management is the responsibility of a set of services: the Delegation, the CredentialsRenewal and the Authorization service. Precisely, the VO-management services manage the security aspects in terms of authentication and authorization mechanisms between of a gCube-based infrastructure’s actors.
+
The VO-Management is composed of:
+
**VO-Management Authorization: (Stub library, WSRF service and API library) A service allowing VO management (VO, VOs hierarchies and gCube system VO Model of Figure 11);
+
** VO-Management Delegation: (Stub library and WSRF service) A service allowing clients to delegate proxy credentials to gCube services running on a GHN;
+
** VO-Management Credential Renewal: (Stub library, WSRF service and API library) A service allowing users to periodically delegate their credentials to GHN.
+
  
From a system wide perspective, the VO-Management services are placed in the gCube Infrastructure Enabling Services. Their main role is to support the entire infrastructure in managing authentication and authorization aspects. Referring to the VO model described in Section 2.3, VOs, Users membership, and users to roles associations are maintained by a VOMS service. In the current implementation VOs are modeled as VOMS groups, while gCube Users and Roles fits with corresponding VOMS Users and Roles.Beyond VOMS functionalities, VO Management services offer a way to manage identities
+
* [[SOA3_Authorization_Module|Authorization]]
of users and services interacting with the infrastructure, through Delegation and Credential Renewal services, and a way to manage authorization rights associated to each role, through the Authorization service.
+
 
 +
* [[Resource_Accounting|Accounting]]
 +
 
 +
* [[SOA3_User_Management_Module|User Management]]
 +
 
 +
are presented.

Latest revision as of 11:20, 4 December 2013


The Virtual Organisation Management (VO-Management) subsystem provides gCube security-related components. It is part of the GCube Infrastructure Enabling Services, and its main aim is to enable the controlled sharing of gCube resources within a gCube infrastructure. The components implement Security As A Service Model (Secaas) and are based on Service Oriented Authorization, Authentication and Accounting (SOA3) framework.

GCube security model is based on the application of security policies for limiting the accessing to services. Basing on this statement, the main entities characterising the security domain are the following:

  • Actors, i.e. the subjects to be authenticated and authorized. In the most of cases they are the human users registered on IMarine Portal or on Federated domains. In other cases the subjects are services that have to perform some batch operations by using any associated identity: in these cases the credentials are X509 Certificates and the authorization policies are based on the attributes of associated service profiles
  • Actions, i.e. the operations that the subjects can or cannot perform. In IMarine context they are service categories, defined by service name and service class: this means that groups of users (or services) can be authorized to use some service categories
  • Resources, i.e. the objects of authorization queries, in other words on what the subject can or cannot perform the operation. In IMarine context resources are service instances, i.e. the actual deployment of the service on a certain node. A service instance is identified by the attributes of the Node on which it is deployed.
  • Policies, i.e. the statements defining which service instances a certain subject can use.

The detailed description of the subsystem is on Data e-Infrastructure Policy-oriented Security Facilities page, where the links to the main functionalities

are presented.