Databases Reference
In-Depth Information
that, for each authorization type
t
, stores
the users for which there is a positive (
n.veclabel
[
t
]
.Allowed
) and negative
(
n.veclabel
[
t
]
.Denied
) authorization of type
t
that applies to
n
. The algorithm
mainly executes the following steps.
∈{
LDH
,
RDH
,
L
,
R
,
LD
,
RD
,
LS
,
RS
}
Step 1:
Authorization retrieval.
Determine the set
A
of authorizations defined
for the document URI at the instance and schema levels and applicable
to the requester in
rq
(i.e., the subject of the authorization is the same,
or a generalization of the requested subject).
Step 2:
Initial
labeling.
For
each
authorization
a
=
A
, determine the set
N
of
nodes that are identified by
a.object
. Then, for each node
n
in
N
,
a.subject
is added to the list
n.veclabel
[
a.type
]
.Allowed
or to the list
n.veclabel
[
a.type
]
.Denied
depending if
a.sign
is + or
subject, object, action, sign, type
∈
, respectively.
Since several authorizations, possibly of different sign, may exist for each
authorization type, the application of a conflict resolution policy is neces-
sary. The final sign
n.veclabel
[
t
]
.sign
applicable to node
n
for each type
t
is then obtained by combining the two lists according to the selected con-
flict resolution policy. The model is applicable and adaptable to different
conflict resolution policies. However, for simplicity it is assumed that con-
flicts are solved by applying the “most specific subject takes precedence”
principle together with the “denials take precedence” principle.
Step 3:
Label propagation.
The labels (signs) associated with nodes are then
propagated to their subelements and attributes according to the following
criteria: (1) authorizations on a node take precedence over those on its
ancestors, and (2) authorizations at the instance level, unless declared
as soft, take precedence over authorizations at the schema level, unless
declared as hard. The nodes whose sign remains undeterminate (
)are
associated with a negative sign since the closed policy is applied.
Step 4:
View computation.
Once the subtree associated with the request has
been properly labeled with +
−
signs, it is necessary to compute the
document's view to be returned to the requester. Note that, even if the
requester is allowed access to all and only the elements and attributes
whose label is positive, the portion of the document visible to the re-
quester includes also start and end tags of elements with a negative label,
but that have a descendant with a positive label. Otherwise, the structure
of the document would change, becoming non compliant with the DTD
any more. The view of the document can be obtained by
pruning
from
the original document tree all the subtrees containing only nodes with a
negative or undefined label. The pruned document may be not valid with
respect to the DTD referenced by the original XML document. This may
happen, for instance, when attributes marked as
#REQUIRED
are deleted
because the final user cannot access them. To avoid this problem, a
loos-
ening
transformation is applied to the DTD, which simply defines as op-
tional all the elements (and attributes) marked as required in the original
−
