206
Maria Luisa Damiani and Elisa Bertino
Example
Finally, we summarize the GEO-RBAC concepts (see Fig. 9.2) by presenting the
access control policy defined for the running example. The policy is built as follows. First, we define the sets of feature types, features, and permissions used in our
policy. Then we specify the following role schemas: the Student schema specifies
that an individual can play the role of student only when located within a campus.
Campus is a spatial feature type and Purdue is an instance of campus. Further, the
logical position of a student is represented by a sector of the campus, of feature type
Sector. The Teacher schema is defined in a similar way for the individuals who are
teachers in the campus. The logical position of a teacher is represented by an address.
The Library Subscriber schema specifies that individuals can play such a role only
within a library. The logical position of a subscriber is of type library. Notice that in
this case, the logical position has the same granularity of the role extent; therefore,
the actual position within the library is not relevant for the application. The role instances we consider are student at Purdue (i.e. Student(Purdue)), teacher in the same
campus (i.e. Teacher(Purdue)), and subscriber of the campus library named MyLib
(i.e. LibrarySubscriber(MyLib)). We then specify how permissions, namely information services, are tied to the previous schemas. For example, the service book-loan of
the running example is assigned to the LibrarySubscriber schema and thus is inherited by its role instances. Now suppose that Sara is a teacher at Purdue, while John
is a student in the same campus and also a subscriber of MyLib. Assume John to be
the only user connected to the system. Until John is outside the Purdue campus, John
is not allowed to access any information service. Conversely, when inside the library
MyLib, John is recognized to be a library subscriber, besides a student, and thus can
request a book loan.
9.5 A Reference Architecture for GEO-RBAC
The GEO-RBAC model defines the conceptual constructs supporting the specification of access control policies. We now complement the discussion by presenting a
reference architecture for an ACS based on GEO-RBAC. The purpose is to devise the
main building blocks of the access control system and at the same time the key operational aspects. We present in particular two different architectural frameworks, the
first relying on a centralized architecture and the other on a distributed architecture
for access control in large-scale applications.
9.5.1 A Centralized Architecture
The centralized ACS assumes that all access control functionalities, namely policy
administration and enforcement, are implemented by a unique component which filters user requests accepting only those which are authorized by the current security
policy. The general architectural framework that we assume is the one shown in
Fig. 9.3. Such framework consists of three fundamental components [11]:
Maria Luisa Damiani and Elisa Bertino
Example
Finally, we summarize the GEO-RBAC concepts (see Fig. 9.2) by presenting the
access control policy defined for the running example. The policy is built as follows. First, we define the sets of feature types, features, and permissions used in our
policy. Then we specify the following role schemas: the Student schema specifies
that an individual can play the role of student only when located within a campus.
Campus is a spatial feature type and Purdue is an instance of campus. Further, the
logical position of a student is represented by a sector of the campus, of feature type
Sector. The Teacher schema is defined in a similar way for the individuals who are
teachers in the campus. The logical position of a teacher is represented by an address.
The Library Subscriber schema specifies that individuals can play such a role only
within a library. The logical position of a subscriber is of type library. Notice that in
this case, the logical position has the same granularity of the role extent; therefore,
the actual position within the library is not relevant for the application. The role instances we consider are student at Purdue (i.e. Student(Purdue)), teacher in the same
campus (i.e. Teacher(Purdue)), and subscriber of the campus library named MyLib
(i.e. LibrarySubscriber(MyLib)). We then specify how permissions, namely information services, are tied to the previous schemas. For example, the service book-loan of
the running example is assigned to the LibrarySubscriber schema and thus is inherited by its role instances. Now suppose that Sara is a teacher at Purdue, while John
is a student in the same campus and also a subscriber of MyLib. Assume John to be
the only user connected to the system. Until John is outside the Purdue campus, John
is not allowed to access any information service. Conversely, when inside the library
MyLib, John is recognized to be a library subscriber, besides a student, and thus can
request a book loan.
9.5 A Reference Architecture for GEO-RBAC
The GEO-RBAC model defines the conceptual constructs supporting the specification of access control policies. We now complement the discussion by presenting a
reference architecture for an ACS based on GEO-RBAC. The purpose is to devise the
main building blocks of the access control system and at the same time the key operational aspects. We present in particular two different architectural frameworks, the
first relying on a centralized architecture and the other on a distributed architecture
for access control in large-scale applications.
9.5.1 A Centralized Architecture
The centralized ACS assumes that all access control functionalities, namely policy
administration and enforcement, are implemented by a unique component which filters user requests accepting only those which are authorized by the current security
policy. The general architectural framework that we assume is the one shown in
Fig. 9.3. Such framework consists of three fundamental components [11]: