Information Technology Reference
In-Depth Information
Fig. 3 Access Right Delegation
2. After successful authentication, user credentials are forwarded to the authoriza-
tion server for the confirmation of his access rights. Request contains
<
Au-
thzDecisionStatement
>
comprising of information regarding
<
Subject
>
,
<
Ac-
attribute.
3. In the next step, user attempts to delegate his access rights by initiating an access
right delegation request.
4. Doctor A is provided with a view where he specifies the required attributes for
policy generation
tion
>
,
<
Resource
>
,
<
Decision
>
and an optional
<
Evidence
>
4.1.
List of doctors that are trusted for him are displayed and he chooses
Doctor B from that list, so that he may access Patient A's records on the
behalf of Doctor A.
4.2.
Action (such as view, edit) is then specified against the patient that the
delegator (Doctor A) wants to delegate
4.3.
Similarly, list of patients is presented so that the Doctor A specifies the
patient name whose record accession rights are to be delegated and from
that list he chooses Patient A .
4.4.
Finally, delegator (Doctor A) specifies the duration, for which the dele-
gatee (Doctor B) can access Patient A's records.
All the required information is submitted to the PAP for the generation of access
control policy. This information includes the identity of delegator (Doctor A),
delegatee (Doctor B), time for which the application is delegated and informa-
tion regarding the resource (Patient A) being delegated.
5. After successful generation of access right delegation token, XACML based
policy is generated and stored at a central policy repository that is accessible to
all the CSPs.
Search WWH ::




Custom Search