Difference between revisions of "Virtual Organisation Management"

From Gcube Wiki
Jump to: navigation, search
(Components)
 
(21 intermediate revisions by 4 users not shown)
Line 1: Line 1:
This page introduces the gCube security model, and related components, part of the Virtual Organisation Management subsystem (VO-Management in the following). The description is organized in three parts: authentication handling is introduced first, detailing the authentication model and mechanism adopted by gCube, as well as components implementing the model. Secondly comes the authorization part, introducing the access control model and authorization-related components implementing it. Lastly, an usage scenario showing interactions among VO-Management services is introduced and described.
+
<!-- CATEGORIES -->
 +
[[Category: Developer's Guide]]
 +
<!-- CATEGORIES -->
  
==Authentication==
+
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.
  
"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>
+
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.
  
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.
+
The detailed description of the subsystem is on [[Data e-Infrastructure Policy-oriented Security Facilities]] page, where the links to the main functionalities
  
'''Delegation'''
+
* [[SOA3_Authentication_Module|Authentication]]
  
In short, delegation is the process of letting a system identity to act on behalf of another identity<ref name="DELEGATION">http://middleware.internet2.edu/webiso/docs/draft-lajoie-trust_and_delegation-02.html</ref>. This is normally needed in distributed N-Tier multi-domain applications to take (limited) advantage of identity privileges grant to the original identity, without the need to assign them to the delegated entity. Identity delegation in gCube then 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.
+
* [[SOA3_Authorization_Module|Authorization]]
  
===Model===
+
* [[Resource_Accounting|Accounting]]
  
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.
+
* [[SOA3_User_Management_Module|User Management]]
  
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).
+
are presented.
 
+
As a consequence of this every authenticated communication between gCube entities is performed using valid credentials, issued by a trusted Certification Authority (CA). As far as the security protocol used during the communication, gCube adopts the HTTPS<ref name="HTTPS">http://en.wikipedia.org/wiki/HTTP_Secure</ref> one. This mechanism provides integrity and privacy, by means of encryption, for authenticated communications. The choice of the HTTPS mechanism to protect gCube interactions, in place of message-level mechanisms like WS-SecureMessage and WS-SecureConversation<ref name="WS_SEC_CONV">http://specs.xmlsoap.org/ws/2005/02/sc/WS-SecureConversation.pdf</ref>, is mainly due to the better performances provided by HTTPS with respect to message-level security mechanisms.
+
 
+
Nevertheless, despite 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.
+
 
+
===Components===
+
 
+
Credentials management is managed in the gCube infrastructure are managed by the following set of VO-Management components:
+
*'''MyProxy''' service - 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>.
+
*'''Delegation''' and '''CredentialRenewal''' services - The Delegation service is in charge to provide 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 and retrieve user's credentials, under a set of predefined delegation policies.
+
 
+
A more detailed description of the structure and behaviour of the authentication-related components can be found in the [[VO-Management_Delegation]] and [[VO-Management_CredentialsRenewal]] pages.
+
 
+
==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."<ref name="WIKI_AUTHZ">http://en.wikipedia.org/wiki/Authorization</ref>.
+
 
+
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 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 in the context of a VO.
+
 
+
===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
+
<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.
+
 
+
 
+
 
+
<center>[[Image:VO_Model.jpg|500px]]</center>
+
 
+
 
+
 
+
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.
+
* '''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.
+
* '''Resource''': This element represents all gCube resources. Each resource is identified through a resource id. Resources have to belong to a resource type.
+
* '''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''': These are logical operations supported by resources of a given type. Sharing rules and Permissions can be defined using these operations.
+
* '''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 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 give them permissions to execute a set of operations.
+
 
+
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, named Attribute Certificate (AC) is signed by a trusted identity on user's request. The AC is embedded in the client certificate and sent to the Running Instance during authentication[<ref name="ATTRIB_CERT">http://www.ietf.org/rfc/rfc3281.txt</ref>]. RIs can thus extract user roles from the received certificate and, knowing the resource id, the scope, and the operation invoked, contact the authorization component asking for an authorization decision.
+
 
+
===Components===
+
 
+
Following main elements are part of the gCube authorization architecture:
+
 
+
* '''VOMS''' - 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 Certificated on user's behalf.
+
* '''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 Running Instances.
+
 
+
==Usage Scenario==
+
 
+
The usage scenario of authentication and authorization componnts in the gCube architecture is shown in the following diagram.
+
 
+
 
+
 
+
<center>[[image:Credentials_Management_Overview.jpg|500px]]</center>
+
 
+
 
+
The diagram above shows interactions occurring in the authentication and authorization of a request from the portal to ta back-end Running Instance.
+
 
+
# When the user logs in the portal, credentials associated with her username/password are retrieved from the MyProxy repository.
+
# The user is then asked to select the VRE where she wants to operate. The selection 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 back-end 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 Authorization Service.
+
 
+
== References ==
+
 
+
<references/>
+
 
+
[[Category:Security]]
+

Latest revision as of 12: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.