Istituto di Scienza e Tecnologie dell'Informazione     
Coppola M., Dazzi P., Carlini E., Righetti G., et al. .. CONTRAIL - Requirements on Federation Management, Identity and Policy Management in Federations. OPEN COMPUTING INFRASTRUCTURES FOR ELASTIC SERVICES. Deliverable D2.1, 2011.
This document describes the requirements for CONTRAIL concerning Federation Support, Identity, and Security. The federation is at the core of CONTRAIL services. Without it, users would need to be concerned with the details of accessing individual service providers, thus, adding the burden of account and resource management to their workload. The CONTRAIL project believes that end users should focus on their work rather than on resource management. It is the role of the federation to broker access to resources, to ensure that the best available resource is selected, and that diverse resources are accessed consistently. The federation thus plays an enabling role for the user. Via the federation, the user accesses resources without being concerned with how this is done. The user typically defines usage policies: limits on the amount of resources to be consumed, privacy requirements, etc. Then, the CONTRAIL federation ensures that the resources are allocated as needed, matching the user's requirements against the published SLAs. Furthermore, users can establish collaborations with other users. It does not matter what the user's home institution is, whether from academia or industry, how they logged in, which country they are based in - unless users want it to matter. The federation must enable users to collaborate across boundaries, but must also let the users impose restrictions based on these boundaries. For example, some data must not leave national (or EU) borders, academic software licenses are often different from commercial, etc. Beyond the user's view, it is also the role of the federation to bring together service providers and users. The cloud model makes resources available on-demand, and users don't have to negotiate directly with individual service providers be- cause the federation establishes contracts between them as needed. The service providers provide services knowing that users agree to acceptable use policies, misuse can be tracked, and use of their resources is accounted. Users, conversely, need not investigate the policies of individual providers, because the federation has examined their published SLAs and selected providers accordingly (and possibly taking in other factors, such as past performance). The CONTRAIL federation provides the potential to make cloud-bursting (scaling out to multiple cloud providers) a routine activity. If required, the federation can also be used to hide information, thus helping preserve privacy. A service provider knows that a legitimate and traceable user has logged in, but do not necessarily need to know who it was. Interactions between all parties are greatly simplified provided that the various actors trusts the federation. In this respect, the federation has a significant responsibility: it must define policies that build trust. In particular, users may entrust the federation with potentially valuable information, such as login details for a remote service provider. The user must be able to place this data into the federation with confidence. The requirements then are gathered from the individual case studies, but also those arising from best practice for operating federations. The case studies focus on end users, but the federation ties together many different actors: users, internal and external service providers, service operators and administrators, owners of datasets. At the same time, the federation must preserve constraints imposed by users, different legislative domains, and cloud infrastructure administration policies. The CONTRAIL project does not aim to build all of this from scratch. When- ever possible, we build on existing work, preferring open and interoperable solutions. CONTRAIL Federations should also improve upon existing SW platforms, which already provide Cloud-bursting functionality and Cloud inter-operation. This document includes a brief survey of existing results. It is worth pointing out there is some overlap with work from other work packages, notably, WP3 (SLAs), WP7 (security), and WP10 (architecture.) There are federation aspects of other work packages as well: for example, a global file system (GAFS, D6.1) requires a global security infrastructure (authentication, access control, logging, etc.)
Subject Cloud Computing
Identity Management
C.1.1 Single Data Stream Architectures
C.5.1 Large and Medium (``Mainframe'') Computers

Icona documento 1) Download Document PDF

Icona documento Open access Icona documento Restricted Icona documento Private


Per ulteriori informazioni, contattare: Librarian http://puma.isti.cnr.it

Valid HTML 4.0 Transitional