GCube Security

Authentication

Model

The gCube Security model uses Public Key Infrastructure (PKI) mechanisms to authenticate identities acting in the infrastructure.

Each authenticated invocation must be performed using valid credentials issued by a trusted Certification Authority (CA).

To speed-up performances of some Running Instances (RI) unauthenticated invocatons are also allowed, even if not included in the design of gCube security. These invocations can be performed without any credentials, neither authentication nor authorization are enforced in these cases.

Mechanism

The mechanism used in gCube to authenticate RI invocatons is the WS-SecureConversation one. The Java WS-Core container provides a built-in implementation of this standard called GSI-SecureConversation.

This choice is driven by the need to delegate caller credentials to invoked RI. The HTTPS mechanism (also available in the Java-WS-Core) cannot interoperate with the GSI-SecureConversation one, thus preventing the exploiting of both mechanisms in the DILIGENT infrastructure. For this reason the HTTPS mechanism has been discarded.

Authorization

Model

Authorization rights in gCube are modeled basing on the RBAC model. This means that each user need to held a valid role to operate in the gCube infrastructure. Following diagram shows the gCube VO model.

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. 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 DILIGENT system. This definition includes every service and agent able to act in the infrastructure. Every user will be univocally identified using a set of user credentials as described in the Authentication section of this page.
• Resource: This element represents all DILIGENT resources. Each resource is unequivocally 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. 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.

Mechanism

A VOMS server maintains the Digital Library (VRE) hierarchy as a VOMS groups hierarchy. It is also in charge to store the set of DILIGENT users and roles assigned to them. An installation of the DVOS Authorization service also reflects the VO hierarchy maintaining sharing rules, permissions and resources set for each role (thus covering the remaining part of the previous diagram).

First of all the user has to log in the portal via HTTP, providing his user name and password, or via HTTPS, using his own credentials installed in the browser. Then the user can select a VRE where to operate clicking on the corresponding tab, this choice can be changed during session simply selecting a different tab in the portal. Each time the user changes the DL where he is working, fresh proxy credentials are created for him and stored in session. These credentials contains all roles the user is entitled to held in that DL.

Credentials are created by the MyProxy service coupled with the gCube CA. Contacting VOMS, credentials are then enriched with roles held by the user in the current VRE. Following deployment diagram shows interactions to retrieve user credentials in the portal and contact a gCube service.

Each invocation (except those performed anonymously) will be authenticated and authorized using the Authorization service. Roles of the user, the operation to be performed and the id of the resource invoked will be sent to the Authorization service in order to obtain an authorization decision.

The VRE context

Authenticated invocations to gCube RI are performed in the context of a VRE. The context is identified from the proxy certificate attached to the request. The user is supposing to operate in the VRE corresponding to the VOMS group that contains at least one role in the proxy credentials.

As a consequence of this choice in gCube all roles included in a proxy certificate must be bound to the same group. This allows to unequivocally identify the VOMS group where the user is operating, thus the corresponding VRE. This of course does not work for unauthenticated invocations.

As a VOMS design choice, all groups the user is member of are always included in the proxy during creation. Role/s to be included need to be explicitly required by the user.

Identities for gCube services

gCube RIs need certificates in order to:

• Autonomously operates in the infrastructure
• Perform further service calls (while serving a request) without the need to impersonate the caller

The Delegation and Credentials Renewal services developed in gCube allows RI to periodically receive fresh credentials to perform invocations.

The CredentialsRenewal service allows users or DILIGENT services to create accounts for the MyProxy repository or for the DILIGENT Online CA. These accounts can then be used to set renewal tasks. Each account contains:

• The user name of the account (on MyProxy or on the Online CA)
• The password of the account (for MyProxy accounts only)
• A set of contexts to limit the usage of the account to a subset of DILIGENT services

Renewal Tasks can be set for each account, tasks set for an account must comply with contexts defined for the account itself. Each task contains:

• The Delegation service where to forward delegated credentials
• The Name of the service where credentials must be dispatched
• A set of VOMS roles to be added to credentials
• A refresh period

Each task periodically retrieve credentials from a MyProxy repository and forward them to the Delegation service co-hosted with the service. The Delegation act as a local dispatcher, notifying the service when fresh credentials are received.

Alongside functionalities provided by these services, the delegation mechanism built-in into the GSISecureConversation protocol is also available. It allows a RI to impersonate the caller.