Page 863 - Cloud computing: From paradigm to operation

Intercloud and interoperability 5

Table I.4 – SSO authentication within inter-cloud environment
Figure
(optional)

Pre- – The CSPs(SaaS) form a federation pattern of inter-cloud.
conditions – The CSPs(SaaS) use a third-party SSO system for implementing SSO authentication functionality
(optional) within their federation.

Post- – The CSC is able to access various services offered by different CSPs once it is successfully
conditions authenticated by any member of the CSPs(SaaS) federation.
(optional)
Derived – SSO authentication (refer to clause 7.4).
requirements – Periodical verification (refer to clause 7.5).

I.5 Use case of control privilege of inter-cloud
This use case illustrates security and control concerns in inter-cloud. The peering pattern of inter-cloud used
to illustrate the use case is an example only.

Table I.5 – Control privilege of inter-cloud

Title Control privilege of inter-cloud
Description – The CSC requests SaaS service from CSPs(SaaS);
– Both CSP1(SaaS) and CSP2(SaaS) use infrastructure including computing and storage
resources from CSP (infrastructure as a service (IaaS)) to provide their cloud services.
Therefore, they all have service instances and data in CSP(IaaS);
– For the sake of CSPs(SaaS) data security and privacy, CSP(IaaS) control over the
infrastructure should be limited to avoid inspection or analysis of CSPs(SaaS) data and
VM instances without explicit CSPs(SaaS) consent;
– CSPs(SaaS) should be able to exercise fine-grained control over protection of their
cloud resources according to a given security SLA. This means that CSPs(SaaS) should
be able to actively monitor their allocated resources;
– CSPs(SaaS) should not be authorized to monitor or modify VM state, service data and
CSC data from other CSCs.
Roles CSCs, CSPs(SaaS), CSP(IaaS).

855