1. Identity Federation in Cloud Computing
SPEDA 2010, August 24, Atlanta
Identity Federation in Cloud Computing
Valentina Casola
Università di Napoli 'Federico II'
Dipartimento di Informatica e Sistemistica
Italy
Massimiliano Rak
Seconda Università di Napoli
Dipartimento di Ingegneria
dell'Informazione
Italy
Umberto Villano
Università del Sannio
Dipartimento di Ingegneria
Italy

2. Rationale Cloud Computing for HPC Introduction Cloud and GRID
Security Issues
PerfCloud
Proposed approach and overall architecture
Access control and Identity Federation in PerfCloud
Conclusions

3. Cloud Computing and HPC
According to the definition of NIST, Cloud Computing is a model for enabling
on demand network access to a shared pool of configurable resources
Cloud Computing delivery models
IaaS (Infrastructure as a Service)‏
SaaS (Service as a Service)‏
AaaS (Application as a Service)‏
Clouds to provide ”servers”, to provide ”application environments”, to provide
”datacenters”,……
Cloud for HPC => IaaS
Performance
Interconnections
Security (give administration rights to consumers)

4. Clouds, GRID and Performance
The use of clouds for HPC makes sense only if performance is satisfactory
The availability of an existing GRID infrastructure is a great opportunity to be exploited
Resources provided by clouds can be used with grid (standard?) access mechanisms
Comparison of Cloud and GRID is an open discussion (management of great number of distributed/computational resources, huge datacenters, different approach towards the applications)

5. PerfCloud: Cloud Computing and GRID Integration
Cloud on GRID:
The complex and stable GRID infrastructure is exploited to build up a cloud environment.
A set of GRID services is offered in order to manage (create, migrate, ...) virtual machines, usually organized in (Virtual) Clusters.
A standard way to access the Cloud (via GRID interfaces – read Web Services interfaces)

6. PerfCloud: The Approach
PerfCloud is a complete framework that provides (virtual) cluster-on-demand functionalities integrated with performance prediction services and a Gui client:
To provide a virtual cluster (with a set of pre- installed applications) with its security domain, giving full management to users
To evaluate on-the-fly the performance of an application on the VC created,
Vc nativi o creati creando vc sopra una cloud con globus precaricato

7. PerfCloud: Overall Architecture
It is composed of:
GRID Services able to manage, evaluate and predict performances of Virtual Clusters
Virtual Clusters Machine Images preconfigured for HPC
Clients for easy access to the environment

8. PerfCloud from a security point of view (1/2): Access Control to virtual and physical resources
Utenti con ruoli differenti e risorse proprietarie:
Cloud User, Cloud Administrator, VC User ecc…
Ci vogliono meccanismi di controllo d’accesso a grana fine basati sul ruolo
Ci vogliono meccanismi di controllo d’accesso che tengano conto di chi possiede la risorsa acceduta
Per favorire la collaborazione tra i vari VC è necessario permettere l’autenticazione di certificati rilasciati da CA differenti:
Ci vuole un meccanismo di federazione
Resources to protect
Available GT4 components

9. Analysis of access control profiles
Diagramma e discussione sui ruoli, prima abbiamo inserito i vari livelli coinvolti
System/GRID Administrator
GRID User
Cloud Administrator
Cloud User
Manage and access physical resources
Manage and access virtual resources

10. PerfCloud from a security point of view (2/2): Authentication and Identity Federation
GRID user authentication is based on digital certificates (x.509 and proxy certificates).
Digital Certificates are accepted if the basic path validation process is successful; it implies that all CA in the certification path are trusted and all certificates are valid.
To validate certificates from external untrusted domains an extended path validation is required; it implies that there is a cross certification among different CAs that can form or not an explicit federation (hierarchical or peer-2- peer), this operation is manually performed.
To fully authomatize the process of extending trust to other CA and so enable the idenity federation, we propose a system to evaluate on-line the CRL and evaluate the security level associated to a CA.

11. POIS: Policy and OCSP based Interoperability System
Enable Extended Path Validation in untrusted Grid domains.
Our approach is to build a dynamic cross certification (federation) of CAs by evaluating their Certificate Policies, on the basis of 3 components:
An automatic policy evaluation methodology (REM),
An OCSP Client (OGRO),
An OCSP Responder (as CertiVer)
In order to define the Certificate Policy and further audit the CA, we refer to a Trusted Third Party .

12. The REM methodology to evaluate a Certificate Policy and extend trust to other CAs
1) formalize a policy according to a common template; 2) each provision is structured and normalized according to a Local Security Level 3) an aggregation function which is based on an Euclidean distance gives the Global Security Level associated to the policy

13. POIS: Policy and OCSP based Interoperability System

14. An example scenario: access to federated resources
basic path validation on the proxy certificate is
performed;
the digital certificate status is evaluated on-line
through the OCSP Responder;
the GSL value is directly retrieved from the POIS (that holds a database with all pre-evaluated Certification Authorities).
the GSL of the Cloud user’s CA is compared against the minimum required-GSL defined by the Federated Grid Container to extend trust, and if GSLV C1 > GSLGC, the validation is successful.
If the extended path validation is successful, the cloud user is mapped to a “federated user”.
Inserisci figura 5 da articolo

15. Role mapping ROLES MAPPING
Requester Req. Resource VO Identity mechanism Role mapped
Root ext. valid feder. lim. user
VC2 ext. valid. feder. user
Root basic valid. same
VC1 basic valid. same
VC1 ext. valid. feder. user
Root

16. PerfCloud Authentication and Authorization mechanisms
Authentication mechanisms:
None.
GSISecureMessage: each individual message is encrypted.
GSISecureConversation: a secure context is established.
GSITransport: transport- level security is provided by using TLS.
Authorization mechanisms:
Container security level (Authzn to access a container);
Service security level (Authzn to access a service);
Resource security level (Authzn to access a resource);
Meccanismi di GT4 ed anche la figura di gt4
WS-Security specification
Policy-based Authzn services

17. Authentication and Authorization Mechanisms
SOAP Mesages
WS-security
Container
Service P E
PDP
CLIENT
Policy Repository
PEP – Policy Enforcement Point
PDP – Policy Decision Point
4 different Auth mechanisms

18. POIS services in PerfCloud
PoisInfoService
PoisFedereationManagementService

19. Conclusions
PerfCloud offers cluster-on-demand functionalities integrated with a simulation environment able to predict user application performance on the newly instantiated Virtual Clusters
We have analyzed cloud-on-grid security issues and in particular, the access control problem and the identity federation among untrusted virtual clusters.
As for access control, we identified the main roles within the PerfCloud and we are able to enforce different security policies to separate the access to physical and virtual resources.
As for identity federation: an innovative interoperability system has been proposed to perform the extended path validation of digital certificates in an automatic way.
Future works:
Performance/security tradeoff (SLA)

20. Thank you for the attention
Any Questions?

21. Implementation status
Physical Cluster Management
Rocks 5.2
Virtualization Engine
Xen 3.2
GRID Layer
Globus (GTK 4.0.8)‏
CerICT GRID
Virtual Workspace (TP2.2, Nimbus-like)‏
Client
CoG Kit

22. Implementation of Access Control Mechanisms
Security descriptors: include authentication and authorization mechanisms to be enforced
At client side we can just configure the authentication method config file
At server side we have container and service security descriptors, while…..
at resource level we have coded a localPDP for authorization …… it overrides the others

23. Case study: PerfCloud Access Control Policies
1) A cloud user can request a Virtual Cluster and can start it up and turn off; 2) A cloud user can start up a VC if and only if he requested the VC; 3) A cloud user can turn off a Virtual Cluster if and only if he started it up; 4) a GRID user cannot manage/access any Virtual Cluster. USERS: Max, Raffaele: Cloud users; Valentina: GRID user.

24. Case study: PerfCloud Access Control Architecture1.
A cloud user request a VC
(steps 1-6 to createResource of
VC type) 2.
A cloud user start up a VC
(steps 7-12 to perform the action
Start up on the assigned VC)
A cloud user stop a VC
Descrivere i vari passi cosa rappresentano

25. Example of a service security descriptor
<securityConfig …. >
<auth-method>
<GSISecureConversation/>
<GSISecureMessage/>
</auth-method>
<authz value="perfCloud:org.globus.
wsrf.impl.security.
authorization.LocalConfigPDP"/>
</securityConfig>
<service name="virtual/core/factory/VirtualService” …..t"> ... <parameter name="securityDescriptor" value="etc/org_globus_virtual_services_ core_factory/security-config-first.xml"/> <parameter name="perfCloud-authzConfigFile" core_factory/localPDP_policy.xml"/> </service>
… OU\=simpleCA-vega.dii.unina2.it/OU\=dii.
unina2.it/CN\=Max={
core/FactoryService}createResource
…. OU\=simpleCA-vega.dii.unina2.it/OU\=dii.
unina2.it/CN\=Raffaele={