Secure Identity Management System for Federated Cloud Environment - Software Engineering, Artificial Intelligence, Networking and Parallel/Distributed Computing - page 24

Step 1. CSC1 registers at CSP1 by providing all the required information to the

Cloud administrators. Cloud administrator then invokes user provisioning
service which is responsible for the creation of user account. Provisioning
module collects necessary user information and stores it in its authorita-
tive identity data store.

Step 2. Provisioning module forwards the information regarding user authentica-

tion to authentication server for the handling of forthcoming authentica-
tion requests.

Step 3. Similarly, information regarding user role and access rights is dispatched

to the authorization server for the formulation and enforcement of access
control policies.

Step 4. After successful user provisioning and distribution of information among

severs, synchronization module will be invoked by the provisioning mod-
ule depending upon the privacy preferences of CSC1.

Step 5. (Optional) In order to synchronize the authoritative identity data stores

Synchronization module makes a connection with CSP2. As a result of
this synchronization an identical account is created on CSP2 as well.
The same process of provisioning will be performed on CSP2, follow-
ing through Step 1 till Step 5 until all the Cloud servers hold identical
user accounts.

4 Use Case Scenario

There are multiple use-cases of proposed secure IDMS for federated Cloud envi-
ronment, such as user-account de-provisioning, user account synchronization, user
carrying out self-service etc. However, here we discuss two possible use-cases of
the proposed system by taking E-healthcare systems as a case-study. In use-case 01,
we explain the process of access right delegation among the subscribers of distinct
but trusted Cloud domains, whereas in use-case 02, we elaborate the steps that the
CSC takes to use the delegated service in an inter-Cloud environment.

4.1 Access Right Delegation (ARD)- Use-Case 01

Use-case 01 depicts an access right delegation scenario, where CSC1 (Doctor A)
is a subscriber of CSP1 and attempts to delegate his access rights on a Patient A's
record to CSC2 (Doctor B) a subscriber of CSP2. In order to perform this dele-
gation, Doctor B must be trusted for Doctor A and CSP1 also. As a result of this
delegation, Doctor B will be able to access and view the medical record of Patient A
on the behalf of Doctor A. A brief overview of the access right delegation use-case
is shown in Figure 3; however, we elaborate each step below,

1. Doctor A forwards his identity credentials in the form of SAML request to the
authentication server for verification.