208
Maria Luisa Damiani and Elisa Bertino
• The status of roles is autonomously checked by an agent tracking the position of
the user connected to the LBS system. As a state transition occurs for a role, that
is, its status changes from enabled to disabled or vice versa, the new status is
recorded and the event is notified to interested system components. The strategy
is thus event-driven.
The simplest approach is the user-driven one because the position of the user
is computed on demand and thus the status of roles is determined only when required. This approach has, however, a major drawback, in that the services which are
available in a given session at a given instant are not known until the user makes an
explicit access request. Therefore, it may occur that the user requires a service which
is not accessible in that position or that the user is not aware of available services at
a given position.
Conversely, when the event-driven strategy is adopted, the status of each role
is determined asynchronously with respect to user requests. Therefore, such information needs to be recorded by the ACS. Although more complex, this approach
overcomes the drawbacks of the user-driven strategy: user requests can be more efficiently processed because the current status of roles is available at the time of the
request and thus need not they be computed; the users can determine the effective
roles can play, before a request is made. Because it is arguably more flexible, the
event-driven approach is the one we adopt.
Event-driven Architecture of the ACS
From an architectural point of view, the proposed organization for the ACS is based
on the following major components:
• The Policy DB is a database storing the security policies specifying, among other
information, the spatial roles, the services available to each role, and the roles
assigned to each user.
• The Session DB records the status of sessions. The status at time t of session s
is represented by the tuple < s, t, S R, ER >, where S R is the set of session roles,
thus the roles selected by the user among those which have been assigned to her;
ER is the set of roles enabled in s at time t.
• An agent called Role Tracker. It periodically retrieves from the Location Server
the position of the users of current sessions and determines whether a state transition has occurred for the roles of each session. If this is the case, the event is
communicated to the Event Manager.
• In response to a Role Tracker event, the Event Manager updates the status of
sessions in Session DB and notifies the event to the corresponding terminal.
This architecture focuses on the operational meaning of access control enforcement. A number of issues however remain open. Among these, a challenging issue
is related to the fact that LBS may be not only of pull type, like for example, directory services (e.g. Where is the closest restaurant), but also of push type. Under the
push model, services are still requested by the user (i.e. subscribed), but the information is provided on a continuous basis. An example is the service which allows one
Maria Luisa Damiani and Elisa Bertino
• The status of roles is autonomously checked by an agent tracking the position of
the user connected to the LBS system. As a state transition occurs for a role, that
is, its status changes from enabled to disabled or vice versa, the new status is
recorded and the event is notified to interested system components. The strategy
is thus event-driven.
The simplest approach is the user-driven one because the position of the user
is computed on demand and thus the status of roles is determined only when required. This approach has, however, a major drawback, in that the services which are
available in a given session at a given instant are not known until the user makes an
explicit access request. Therefore, it may occur that the user requires a service which
is not accessible in that position or that the user is not aware of available services at
a given position.
Conversely, when the event-driven strategy is adopted, the status of each role
is determined asynchronously with respect to user requests. Therefore, such information needs to be recorded by the ACS. Although more complex, this approach
overcomes the drawbacks of the user-driven strategy: user requests can be more efficiently processed because the current status of roles is available at the time of the
request and thus need not they be computed; the users can determine the effective
roles can play, before a request is made. Because it is arguably more flexible, the
event-driven approach is the one we adopt.
Event-driven Architecture of the ACS
From an architectural point of view, the proposed organization for the ACS is based
on the following major components:
• The Policy DB is a database storing the security policies specifying, among other
information, the spatial roles, the services available to each role, and the roles
assigned to each user.
• The Session DB records the status of sessions. The status at time t of session s
is represented by the tuple < s, t, S R, ER >, where S R is the set of session roles,
thus the roles selected by the user among those which have been assigned to her;
ER is the set of roles enabled in s at time t.
• An agent called Role Tracker. It periodically retrieves from the Location Server
the position of the users of current sessions and determines whether a state transition has occurred for the roles of each session. If this is the case, the event is
communicated to the Event Manager.
• In response to a Role Tracker event, the Event Manager updates the status of
sessions in Session DB and notifies the event to the corresponding terminal.
This architecture focuses on the operational meaning of access control enforcement. A number of issues however remain open. Among these, a challenging issue
is related to the fact that LBS may be not only of pull type, like for example, directory services (e.g. Where is the closest restaurant), but also of push type. Under the
push model, services are still requested by the user (i.e. subscribed), but the information is provided on a continuous basis. An example is the service which allows one