Databases Reference
In-Depth Information
of establishing such agreement is based on a structure called an
application
domain specification document
(ADSD) [46]. ADSDs contain natural-language
descriptions of role names that pertain to a given application domain. They
can also be used to specify other technical information useful for ensuring
consistent use of these role names, such as how many parameters of what
types are required for each role name. ADSDs are made available on the web
via a universal resource identifier (a web address) that can serve not only as
a locator, but also as an identifier of the vocabulary defined by the ADSD.
Credentials that make use of these role names can use this identifier along
with the role name to disambiguate the intended meaning.
3.5 OASIS and Cassandra
OASIS [67, 26, 28] and Cassandra [5, 6] are role-based trust management
systems that have many design considerations in common. Cassandra was in-
fluenced by the OASIS design. However, while OASIS was designed for general
purpose use, Cassandra was designed with the goal of supporting the access
control policies for a national electronic health record system.
OASIS introduced the notion of appointment. Appointment occurs when a
member of some role issues an
appointment credential
that will allow some user
to activate another role [67]. Thus appointers belong to roles that resemble
administrative roles in RBAC [56].
OASIS uses first-order logic clauses to represent security policy. For ex-
ample, “
r
1
,w
1
r
4
” is a policy statement that means a user who is active in
role
r
1
and holds the appointment certificate
w
1
can activate the role
r
4
.
As in
RT
1
, roles in Cassandra are parameterized. Cassandra represents pol-
icy statements as Datalog clauses with constraints. One interesting character-
istic of Cassandra is that its expressivity can be tuned by selecting constraint
systems having differing complexity (as discussed further in Section 4).
Unlike most trust management systems, OASIS and Cassandra support
the notion of a
session
. In this respect, they are unique among the systems
we discuss here and thus are perhaps the most justified in calling themselves
role-based. Indeed, some researchers have been critical of characterizing lan-
guages such as
RT
as being role-based, because they have no notion of session.
On the other hand, the presence of sessions introduces a highly dynamic com-
ponent of system state into OASIS and Cassandra not present in other trust
management systems, which raises serious concerns about scalability in highly
distributed systems.
Cassandra makes the interesting choice of implementing some aspects of
session state within extensional Datalog relations. There are six predefined
predicates in Cassandra:
permits
(
e, a
) holds if entity
e
can perform action
a
;
canActivate
(
e, r
) holds if
e
can activate role
r
;
hasActivated
(
e, r
) holds
if
e
has activated
r
;
canDeactivate
(
e
1
,e
2
,r
) holds if
e
1
has the power to
deactivate
e
2
's activation of role
r
;
isDeactivated
(
e, r
) holds if role
r
has been
deactivated for entity
e
;
canReqCred
(
e
1
,e
2
.p
(
e
)) holds if
e
1
is permitted to
