Difference between revisions of "GCube Security Model"
| Line 24: | Line 24: | ||
As a consequence of this choice in DILIGENT all roles included in a proxy certificate must be bound to the same group. This allows to uniquelly identify the VOMS group where the user is acting and thus the corresponding DL. This of course does not work for unauthenticated invocations. | As a consequence of this choice in DILIGENT all roles included in a proxy certificate must be bound to the same group. This allows to uniquelly identify the VOMS group where the user is acting and thus the corresponding DL. This of course does not work for unauthenticated invocations. | ||
| − | ==Identity of services acting in a Single DL== | + | ==Identities for DILIGENT services== |
| + | DILIGENT services need certificates in order to: | ||
| + | * Autonomously operates in the infrastructure | ||
| + | * Perform further service calls (serving a request) without the need to impersonate the caller | ||
| + | |||
| + | ===Identity of services acting in a Single DL=== | ||
These services needs | These services needs | ||
| − | ==Identity of services acting in mutiple DLs== | + | ===Identity of services acting in mutiple DLs=== |
Revision as of 17:34, 14 March 2007
This page describes the security model adopted in the DILIGENT infrastructure
Contents
Authentication Model
The DILIGENT 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 services unauthenticated invocatons are also allowed, even if not planned in the design of DILIGENT security. These invocations can be performed without any credentials, neither authentication nor authorization is enforced in these cases.
Authentication Mechanism
The mechanism used in DILIGENT to authenticate service 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 services. 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 Mechanism
Authorizations for each Digital Library (DL) are managed separately. A VOMS server maintains the DL hierarchy as a VOMS groups hierarchy. Roles are defined globally in DILIGENT and are granted to users in a DL (thus in a VOMS group). When a user log in the portal fresh proxy credentials are created for it. These credentials contains roles held by the user during session. As a VOMS design choice, all groups the user is member of are always included in a proxy certificate when the VOMS is contacted. Role/s held by the user in a group need to be explicitly required by the user at proxy creation.
The DL context
Authenticated invocations to DILIGENT services are performed in the context of a DL. The context is identified from the proxy certificate attached to the request. The user is supposing to operate in the DL corresponding to the VOMS group that contains at least a role in the proxy credentials. As a consequence of this choice in DILIGENT all roles included in a proxy certificate must be bound to the same group. This allows to uniquelly identify the VOMS group where the user is acting and thus the corresponding DL. This of course does not work for unauthenticated invocations.
Identities for DILIGENT services
DILIGENT services need certificates in order to:
- Autonomously operates in the infrastructure
- Perform further service calls (serving a request) without the need to impersonate the caller
Identity of services acting in a Single DL
These services needs
