Information Technology Reference
In-Depth Information
EA+ : notified event is subscribed to;
(2-1)
EA- : notified event is not subscribed to;
(3-1)
Another authorisation cluster has behaviour authorisation (BA) rules:
BA+ : subject (identity) is authorised to request action a
i
;
(2-2)
BA- : subject (identity) is not authorised to request action a
i
;
(3-2)
Obligation cluster has rules for behaviour (
BO
) and for notification (
NO
):
BO+ : subject (identity) must request action a
i
;
(4-1)
BO- : subject (identity) must not request action a
i
;
(5-1)
NO+ : monitor must notify on action a
i
;
(4-2)
NO- : monitor must not notify on action a
i
;
(5-2)
Service Domain (SD)
Behaviour Rules Design
SD Component
SD Component
E
v
ent ~request (T,
a
)
Su | BO+
BA+ | Ob (
a
)
EA
A
EA
S
Security Rules
D
esign
Event ~
state notification
Event ~
o
bligation trigger
M | NO+
M | NO+
Notification Rules Design
Legend
: Su - subject, Ob - target object; M - montor; BO - behaviour obligation;
BA - behaviour authorisation; EA - event authorisation; NO - notification obligation
Fig. 1.
Rule-based system security model
In highly dynamic rule-based systems we want to allow new rules to be injected by
rule designers at run time, therefore we need a very fine-grained conflict resolution
mechanisms. Not every rule-based system can be made capable of this, but event
based systems can: events are glueing together all parts of the system (more precisely,
all components of a service domain), and behaviour definition enforces this glue into
operation. In general,
eventing
makes a denser mesh of entities within a service do-
main thus helping to achieve higher level of self-awareness.
