Information Technology Reference
In-Depth Information
both with negative and positive modalities. Note, that obligation policy and the nega-
tive modality of authorisation policy are not within a mainstream of role-based access
control (RBAC) work, for example, proposed NIST standard for RBAC [3] does not
include negative permissions.
We intend to demonstrate that obligation policy is an extremely useful notion for
network programmability. For the rest of the paper we assume the following interpre-
tations of (1) for positive (
+
) and negative (
-
) authorisation (
A
) and obligation (
O
)
policies:
A+ : Subject's request for action a
i
on Ob will be authorised
(2)
A - : Subject's request for action a
i
on Ob will be denied,
(3)
O+: Subject must request action a
i
on Ob,
(4)
O- : Subject must refrain from requesting action a
i
on Ob
(5)
Table 1 highlights differences between
Su
and
Ob
in their relation to a policy.
Table 1.
Entity type
Role
Configured policy
Discovered policy
Policy pur-
pose
Ob
Object
Server
Authorisation
Obligation
Safeguard
Su
Role
Client
Obligation
Authorisation
Behaviour
In a real world a target object (a
server
) is a tangible entity that may perform a use-
ful work — it is functionality, while a subject (a
client
) is basically a role, an abstrac-
tion. Policies (
A
at
Ob
, and
O
at
Su
) have to be
configured
, that is designed, instanti-
ated and enforced. How this is done? Who does it? Answers to these questions
become important when policy dynamics are concerned. Policies of a counter-part can
be discovered at run-time, that is a subject may discover whether she is authorised to
request certain actions on certain objects. Finally, the very purpose of authorisation
policy is to be a safeguard for actions of a target object; on contrary to that obligation
policies have a very active nature - they basically describe behaviour of a subject as
observed by objects in the object world. From Table 1 it is clear, why obligation poli-
cies have to be based on subject - be embedded into subject's behaviour, and authori-
sation policies have to be based on object - to serve as embedded protection for ob-
ject's desired behaviour, i.e. service.
3
Dynamic Behaviour Changes
We would like to be able to change dynamically behaviours of involved objects to
cater for new and tailored
network
services. The boundary between client and server
is increasingly a blurring one in novel Internet protocols. User application requesting
a connection service from transport and IP modules in its local protocol stack triggers
multiple
micro
client-server exchanges within the network needed to complete the
connection (examples are address resolution, address translation, configuration, au-
thorisation, etc.), thus making a
transaction
from any Internet session. The above
example may not necessarily be a convincing one because transaction components are
relatively small, fast and efficiently integrated (embedded) into a protocol stack,
which by the way makes protocol stacks so difficult to modify. Emerging web ser-