210
Maria Luisa Damiani and Elisa Bertino
ACS, the system is expected to grant access to the services assigned to students.
Now the question which arises is how can the system trust John. In a centralized
architecture, the answer is simple since the ACS maintains information on users
and on all pairs user–role (user–role assignment relation). Therefore when John is
first authenticated and then presents his role, the ACS verifies whether the binding < John, student > is specified in the user–role assignment relation. In a distributed context, however, this approach is not flexible enough: when a new user is
entered into or removed from the system or a new role is assigned or deassigned
to a user, such information must be replicated in every local policy. Such operation
results not only are tedious and complex to manage but can also lead to inconsistent
polices.
We adopt thus a different approach. The idea is that the user first obtains a digital
certificate which specifies the user’s role; then this certificate is presented to the ACS
to certify the role assignment for the user and to subsequently grant the access to the
requested service. The advantage of this approach is that the user-role assignment
relation does not need to be specified at the level of local policy.
Digital certificates contain a number of attributes, such as the name, a serial
number, expiration dates, and the digital signature of the certificate-issuing authority so that a recipient can verify that the certificate is real. Moreover, certificates
hold spatial role information (role certificates). As far as we know, the idea of
certificates containing spatial information has been not explored yet. The certification authority in charge of issuing role certificates is called role provider. User–
role authentication is then performed as follows: the user downloads certificates
from the role provider, one for each role, and stores them on his mobile terminal.
To invoke a service, the user first selects the certificate corresponding to the role
he wants to play in the interaction and then transmits it to the application server
along with the service requests. In such a way, the user is authenticated along with
his role.
Decentralized Policy Enforcement
Suppose now that a user, after being authenticated, requests the permission of invoking a service. Following the GEO-RBAC model, such permission is granted only if
the user is located within the extent of a spatial role authorized to request that service. The question we now address is how to assess whether a relationship of spatial
containment holds between the user position and the role extent. A first solution is
to apply the same approach adopted in the centralized architecture, that is, the ACS,
which receives the user’s request, obtains the position of the user from the location server and then, based on role information, determines whether the containment
constraint is satisfied. The drawback of this approach is that in large applications,
it introduces a significant communication burden. We thus opt for a different solution in which policy enforcement is initiated on clients. The idea is as follows: since
clients have knowledge of the roles assigned to users because of the role certificates
stored on terminals, clients are potentially able to reject requests which cannot be
satisfied and thus avoid sending useless requests to the servers. For this approach to
Maria Luisa Damiani and Elisa Bertino
ACS, the system is expected to grant access to the services assigned to students.
Now the question which arises is how can the system trust John. In a centralized
architecture, the answer is simple since the ACS maintains information on users
and on all pairs user–role (user–role assignment relation). Therefore when John is
first authenticated and then presents his role, the ACS verifies whether the binding < John, student > is specified in the user–role assignment relation. In a distributed context, however, this approach is not flexible enough: when a new user is
entered into or removed from the system or a new role is assigned or deassigned
to a user, such information must be replicated in every local policy. Such operation
results not only are tedious and complex to manage but can also lead to inconsistent
polices.
We adopt thus a different approach. The idea is that the user first obtains a digital
certificate which specifies the user’s role; then this certificate is presented to the ACS
to certify the role assignment for the user and to subsequently grant the access to the
requested service. The advantage of this approach is that the user-role assignment
relation does not need to be specified at the level of local policy.
Digital certificates contain a number of attributes, such as the name, a serial
number, expiration dates, and the digital signature of the certificate-issuing authority so that a recipient can verify that the certificate is real. Moreover, certificates
hold spatial role information (role certificates). As far as we know, the idea of
certificates containing spatial information has been not explored yet. The certification authority in charge of issuing role certificates is called role provider. User–
role authentication is then performed as follows: the user downloads certificates
from the role provider, one for each role, and stores them on his mobile terminal.
To invoke a service, the user first selects the certificate corresponding to the role
he wants to play in the interaction and then transmits it to the application server
along with the service requests. In such a way, the user is authenticated along with
his role.
Decentralized Policy Enforcement
Suppose now that a user, after being authenticated, requests the permission of invoking a service. Following the GEO-RBAC model, such permission is granted only if
the user is located within the extent of a spatial role authorized to request that service. The question we now address is how to assess whether a relationship of spatial
containment holds between the user position and the role extent. A first solution is
to apply the same approach adopted in the centralized architecture, that is, the ACS,
which receives the user’s request, obtains the position of the user from the location server and then, based on role information, determines whether the containment
constraint is satisfied. The drawback of this approach is that in large applications,
it introduces a significant communication burden. We thus opt for a different solution in which policy enforcement is initiated on clients. The idea is as follows: since
clients have knowledge of the roles assigned to users because of the role certificates
stored on terminals, clients are potentially able to reject requests which cannot be
satisfied and thus avoid sending useless requests to the servers. For this approach to