Information Technology Reference
In-Depth Information
vices will and are already providing much more visible examples of transactional
behaviour, because a
service
becomes a concern that is clearly separated from under-
lying functionality and thus can be separately defined, designed, implemented, man-
aged and optimised.
In current IP networking these micro-clients and micro-servers are sitting back to
back to play both
roles
interleavingly, as in Table 1. Hence, a new service will need to
modify behaviours of both involved component types - subjects and objects. In the
above, traditionally understood subject, representing a human, or a role within organ-
isational hierarchy is not directly involved in micro-exchanges but a requestor always
conveys subject's
identity
to a requesting entity. Subject's identity may become
anonymous through aggregation, however methods have been already developed
capable in principle of tracing back to a source any single IP datagram.
In our adopted policy framework (section 2) to change behaviour dynamically
would mean to change
O
and
A
policies
correspondingly
in order to avoid conflicts. A
taxonomy of policy conflicts and static conflict resolution methods are described in
[4]; many policy conflicts can be detected only at run-time due to their dependencies
on object's state data, enforcement point location, and on already enforced policies,
etc. Introduction of a
new network servic
e will require
new behaviours
from network
components, hence new, or
modified policies
will be needed. We shall use the term
behaviour definition
for a set of policies enabling altogether a new network service.
Extending a policy domain (a concept of grouping together entities with similar
policies) we propose a concept of
service domain
- a group of subjects and objects
with their
matching
obligation and authorisation policies pertaining to the same ser-
vice. The following definition of service is adopted from [5]:
Service.
A Logical Element that contains the information necessary to represent and
manage the functionality provided by a Device and/or Software Feature. A Service is
a general-purpose object to configure and manage the implementation of functional-
ity. It is not the functionality itself.
We consider a set of obligation policies to map to a service in the above definition,
while target object with its authorisation policies clearly maps to a logical element.
There can be many types of
A
↔
O
dynamic, at run-time relations binding service to
functionality, such as one to one, one to many, many to one, multi-tier, etc. Creation
of a new service is to be accompanied by creation of a service domain. Service do-
main is an abstraction to compartment all rules involved in a service and in the ex-
change of all events triggering these rules.
4
Events, Monitors, and the Need for Odd Policies
An event, as previously defined in [6] is
E = <A, B, C, D>
(6)
That is an event is a set of post conditions (
C
) produced by an action
A,
which did
happen in the network element (box)
B
, which post-conditions are considered to be
valid during a period
D
. From a security viewpoint event's element
B
bears subject's
