3.4. Access Control in Distributed Systems

Access control mechanisms are particularly critical for today’s distributed systems, in which applications and users need to interact across different administrative domains. Moreover, several new applications are emerging, such as collaborative applications, workflows, and grid computing, for which different access control policies may need to be combined. Some important requirements for suitable access control systems in such context are:

• Authorizations should be expressed in terms of the qualifications and characteristics (i.e., attributes) of subjects, rather than being expressed in terms of user log-in names. In many cases, users of web applications do not have local log-in names, because in practice managing log-in accounts for a dynamically changing population of users is not feasible. Recent approaches to access control for distributed systems are based on the notion of attribute-based access control (ABAC); this is the case of the XACML standard and of more advanced models, like Author-X [12]. When adopting ABAC, however, there is the issue of how to exchange assertions about values for these attributes and whether these assertions can be trusted. SAML, briefly described in the following subsection, addresses the first of such issues. We discuss issues related to trust also in the context of the discussion about SAML.

• Contextual information should be taken into account in access control decisions. In several applications characterized by mobile users, it is crucial, for example, that access to sensitive resources is only performed when the user is located in specific locations. A model supporting this requirement is GEO-RBAC, which is briefly discussed in Section 3.4.2.

In the remainder of this section, we elaborate on some of the relevant standards, and then we discuss advanced solutions and research issues.

3.4.1. Overview of Relevant Standards

The standard world has been very active in developing standards related to XML and more recently to web services technology. Those standards cover many security components and techniques, ranging from encryption to digital signature techniques and access control. Here, we briefly review the standards that are more relevant in the context of access control, namely SAML and XACML.

SAML

The Security Assertions Mark-up Language (SAML) [5] is an XML-based framework, developed by OASIS, to support the exchange of security information, also called trust assertions, between parties in a distributed system. The applications and environments that can use SAML range from simple browser-based applications to more complex n-tiered architecture web services. Security information takes the form of security assertions, where an assertion states certain facts (characteristics and attributes) about a subject. The current SAML framework supports three kinds of security assertions: authentication, attribute, and authorization decisions. Specifically:

• An authentication assertion states that the subject S has been authenticated by means of an authentication method M at a certain time. It is issued by the party that successfully authenticated the subject.

• An attribute assertion states that the subject S is associated with the set of attributes A with values B (e.g., that Alice is associated with attribute “Company” with value “Hertz”).

• An authorization decision assertion states that a subject S has been authorized to execute an action on resource R (e.g., that a user has been authorized to use a given service).

Assertions are issued by SAML authorities, namely authentication authorities, attribute authorities, or policy decision points. In order to support the exchange of security assertions between involved parties, SAML provides a request and response protocol that consists of XML-based messages; a client uses this protocol to request a specific assertion or to make authentication, attribute, and authorization decisions queries to an SAML authority. These messages can be bound to many different underlying communication and transport protocols.

SAML also defines several profiles. Generally, a profile of SAML defines constraints and/or extensions of the core protocols and assertions in support of the usage of SAML for a particular application by specifying how particular statements are communicated using appropriate protocol messages over specified bindings. For example, the Web Browser SSO Profile specifies how SAML authentication assertions are communicated using the Authentication Query and Response messages over a number of different bindings in order to enable single sign-on for a browser user. SAML assumes that the two or more endpoints of an SAML transaction are uncompromised, but the attacker has complete control over the communications channel.

SAML has been successfully used in a number of systems, such as those for federated digital identity management, that are discussed in a later section. However, it is important to emphasize that SAML does not address the problem of the use of assertions once they are received by a party, nor whether these assertions can be actually trusted. In particular, trust in such context consists of two different requirements: being able to trust the keys used to sign the assertions and being able to trust the actual content of the assertion. The first requirement can be easily addressed by the use of key infrastructures. The second requirement is much more difficult to assess, in that an assertion may convey information that is not correct because of errors made by the issuing party or because the issuing party did not adequately verify the information. Addressing such requirements is much more challenging, and it requires adopting organizational measures in addition to technical techniques. Research in the area of data quality, which aims at developing techniques to improve the quality of digital data, may be very relevant to address such requirements.

XACML

XACML [6] provides an extensible, XML-encoded language for managing authorization decisions. To this end, XACML language allows one to express access control policies and access requests/responses. XACML was conceived as one component of a distributed and interoperable authorization framework, with the following underlying rationales:

It is worth noting that XACML also includes a non-normative data flow model (see [6], Section 3.1, Data Flow Model), reported in Figure 3.3, that describes the major components involved in processing of access requests. This model, which can be considered as an evolution of the ISO 10181-3 model [13], can be used as a reference model for the implementation of an XACML engine. The components of such a model are:

• The Policy Administration Point (PAP) supports authorization policy authoring and stores the authored policies in the appropriate repository.

• The policy enforcement point (PEP) performs access control by making decision requests and enforcing authorization decisions.

• The policy information point (PIP) serves as the source of attribute values or the data required for policy evaluation.

• The policy decision point (PDP) evaluates the applicable policy and renders a response to the PEP containing the authorization decision. The possible response values are: Permit, Deny, Indeterminate (in case an error occurred or some required value was missing, so a decision cannot be made), or Not Applicable (the request cannot be answered by this service).

  Figure 3.3. Data flow model for XACML. From OASIS [6].

  

The PEP and PDP both might be colocated within the same application, or might be distributed across different servers. In XACML, the access request is represented by the Request schema that specifies the requesting Subject, the requested Object, and the specific Action requested on the Object. The XACML policy language was designed to be general enough so as to describe general access control requirements. It is also extensible, by means of standard extension points, in order to accommodate the definition of new functions, data types, combining logic, and so forth.

In XACML, a policy is the smallest element that the PDP can evaluate. A policy represents a single access control policy, expressed through a set of Rules. A Rule specifies the Target that it applies to and the effect of the Rule, such as Permit or Deny. The Target basically models the access request by means of a set of simplified conditions for the Subject, Resource, and Action that must be met (i.e., evaluate to true) for the Rule to apply to a given request. Any number of Rule elements may be used, each of which generates a true or false outcome. Combining these outcomes yields a single decision for the Policy, which may be “Permit,” “Deny,” “Indeterminate,” or a “Not Applicable” decision. As a policy example, consider the following: “MPEG movie for adults cannot be accessed by users with age less than 18 years.” The movie is the resource that the access to must be controlled; it will be modeled by an element having an attribute “category.” Similarly, the subject will have an attribute “age.” In this case, the policy is composed by a single Rule that specifies the condition—“age less than 18 years”—for the subject; the condition—category = “adult only”—for the resource; the condition—“download”—for the action: and the effect—“Deny.” More than one Rule (or policy) may be applicable to a given access request; XACML defines a set of Combining Algorithms to reconcile multiple outcomes into a single decision, namely, Deny-overrides, Permit-overrides, First-applicable, or Only-one-applicable. Recently, an OASIS XACML Profile for Web-Services, hereafter referred to as XACML2, has been developed in order to support access control for web services.

Even though XACML has contributed to make widely known important research notions developed by academia, such as attribute-based and credential-based access control [12], it also has some drawbacks. It has been designed to be used in applications in which there is a centralized administration; it is also very complex and thus analysis of XACML policies is quite difficult. A recent paper [14] provides preliminary results concerning the integration of XACML policies for independently administered domains. However, such an approach is very preliminary and more research is needed on this topic.

3.4.2. Advanced Approaches

Recent advanced approaches to access control in distributed systems have mainly focused on the problem of how a system can control access when users are not previously known to the system. Most such approaches rely on the use of credentials that users wishing to access resources management by a party have to provide. In what follows, we describe first an approach in which access is given based on a credential exchange process; we refer to such a process as trust negotiation. We then discuss the case in which the resource to which access has to be controlled is a set of roles; therefore, the issue is how to automatically verify that users, from an administrative domain, have the right to log-in under a role in another administrative domain. Another important issue that has been recently investigated is related to mobile users that need to access certain resources; user location is thus an important contextual parameter that should be taken into account when deciding whether a user can access a given resource. This is a critical issue for many applications that require that access to critical resources be only possible when the user is in a secure location. In this section we discuss Geo-RBAC [15], the first comprehensive approach addressing such a requirement.

Trust and Trust Negotiation

The notion of trust is a key notion in distributed systems, in which very often parties unknown to each other need to communicate in order to exchange information and share resources. Trust is a complex notion about which no consensus exists in the computer and information science literature, although its importance has been widely recognized. Different definitions are possible depending on the adopted perspective. For example, Kini and Choobineh [16] define trust from the perspectives of personality theorists, sociologists, economists, and social psychologists. Their definition of trust is: “A belief that is influenced by the individual’s opinion about certain critical system features.” A different definition is based on the notion of competence and predictability. The Trust-EC project (http://dsa-isis.jrc.it/TrustEC/) of the European Commission Joint Research Centre (ECJRC) defines trust as: “The property of a business relationship, such that reliance can be placed on the business partners and the business transactions developed with them.” Such a definition emphasizes the identification and reliability of business partners, the confidentiality and integrity of sensitive information, the guaranteed quality of digital goods, the availability of critical information, and the dependability of computer services and systems. Another relevant definition is by Grandison and Sloman [17] who define trust as: “The firm belief in the competence of an entity to act dependably, securely, and reliably within a specified context.” They argue that trust is a composition of many different attributes—reliability, dependability, honesty, truthfulness, security, competence, and timeliness—that may have to be considered depending on the environment in which trust is being specified.

A main difficulty of all these definitions, as well as others, is that they provide a notion of trust for which establishing metrics and developing evaluation methodologies is quite difficult. A more restricted notion of trust, which is the one underlying trust negotiation systems, was initially proposed by Blaze et al. [18] according to whom, “Trust management problems include formulating security policies and security credentials, determining whether particular sets of credentials satisfy the relevant policies, and deferring trust to third parties.” Such a definition of trust basically refers to security policies regulating accesses to resources and credentials that are required to satisfy such policies, and it is thus very relevant in the context of access control for distributed systems.

Trust negotiation refers to the process of credential exchanges that allows a party requiring a service or a resource from another party to provide the necessary credentials in order to obtain the service or the resource [19]. Access control policies are expressed in terms of conditions against the possession of specific credentials and properties. Notice that, because credentials may contain sensitive information, the party requiring the service or the resource may ask to verify the other party’s credentials before releasing its own credentials. Trust negotiation is a peer-to-peer interaction and consists of the iterative disclosure of digital credentials, representing statements certified by given entities, for verifying properties of their holders in order to establish mutual trust. In such an approach, access to resources (data and/or services) is possible only after a successful trust negotiation is completed.

A trust negotiation system typically exploits digital identity information for the purpose of providing a fine-grained access control to protected resources. However, unlike conventional access control models, trust negotiation assumes that the interacting parties are peers and that each peer needs to be adequately protected. For instance, with respect to the peer owning the resource to be accessed, assets that need to be protected are, in addition to the resource, the access control policies, as they may contain sensitive information, and the credentials of the resource owner. With respect to the peer requiring access to the resource, the assets to be protected are the credentials, as they often contain private information about the individual on behalf of whom the peer is negotiating.

We now briefly describe how negotiations are generally intended and identify the main phases and functional components of negotiations as given in Bertino et al. [19]. Trust negotiation typically involves two entities, namely a client, that is, the entity asking for a certain resource, and a server, that is, the entity owning (or more generally, managing access to) the requested resource. The model is peer-to-peer: Both entities may possess sensitive resources to be protected and thus must be equipped with a compliant negotiation system. The notion of resource comprises both sensitive information and services, whereas the notion of entity includes users, processes, roles, and servers. The term resource is intentionally left generic to emphasize the fact that the negotiations we refer to are general purpose, that is, a resource is any sensitive object (e.g., financial information, health records, and credit card numbers) whose disclosure is protected by a set of policies.

Figure 3.4 illustrates a typical negotiation process. During the negotiation, trust is incrementally built by iteratively disclosing digital credentials in order to verify properties of the negotiating parties. Credentials are typically collected by each party in appropriate repositories, called subject profiles. Another key component is the set of access control policies, referred to as disclosure policies, governing access to protected resources through the specification of the credential combinations that must be submitted to obtain access to the resources. To carry out a trust negotiation, parties usually adopt a strategy, which is implemented by an algorithm determining which credentials to disclose, when to disclose them, and whether to succeed or fail the negotiation. Several trust negotiation strategies can be devised, each with different properties with respect to speed of negotiations and caution in releasing credentials and policies [20].

Because of the relevance of trust negotiation for web-based applications, several systems and research prototypes have been developed. Well-known systems include Keynote [18] and Trust-X [19].

Keynote has been developed to work for large- and small-scale Internet-based applications. It provides a single, unified language for both local policies and credentials. Keynote credentials, called assertions, contain predicates that describe the trusted actions permitted by the holders of a specific public key. As a result, Keynote policies do not handle credentials as a means of establishing trust, mainly because the language was intended for delegation authority; also, Keynote does not support optimization strategies and does not address the problem of privacy.

Trust-X is a more advanced system that supports all aspects of negotiation; it supports an XML-based language, known as X-TNL, for specifying Trust-X certificates and policies. Trust-X has a typing credential system and addresses the issue of vocabulary agreement using XML namespaces. The use of namespaces combined with the certificate-type system helps the trust negotiation engine in correctly interpreting different credentials’ schema, even when issued by different entities not sharing a common ontology.

A novel aspect of X-TNL is its support for special certificates, called trust tickets. Trust tickets are issued upon successfully completing a negotiation and can speed up subsequent negotiations for the same resource. X-TNL provides a flexible language for specifying policies and a mechanism for policy protection, based on the notion of policy preconditions. A Trust-X negotiation consists of a set of phases that are sequentially executed. In particular, Trust-X enforces a strict separation between policy exchange and resource disclosure. This distinction results in an effective protection of all the resources involved in negotiations.

Trust-X also provides various trust negotiation strategies that allow one to trade-off between efficiency and protection requirements. In particular, Trust-X supports three different negotiation modes. The first, based on trust tickets, can be adopted when the parties have already successfully completed a negotiation for the same resource. The second mode, based on using specific abstract data structures called negotiation trees, performs a runtime evaluation of the negotiation’s feasibility by determining a sequence of certificate disclosures that can successfully end the negotiation. The last mode exploits a notion of similarity between negotiations, and is based on the observation that a service provider usually handles many similar negotiations. Recent investigation carried out in the framework of Trust-X includes support for privacy [21], anonymity [22], the development of a recovery protocol [23], and the integration with federated identity management [24].

Multidomain RBAC

The Web has made possible a large variety of collaborative applications, in areas such as e-learning, healthcare, and e-government. Most of these applications require different organizations, or even different units within the same organization, to be able to establish dynamic coalitions in which users of one domain can seamlessly access resources from other domains. Approaches in which users are explicitly and directly given access to all resources they need to access across the coalition domains are not practical and do not scale. Moreover, they make authorization revocation cumbersome and error prone. Different approaches are required to keep the administration costs at a reasonable level and supporting a manageable authorization revocation.

One such approach has been recently proposed based on the X-GTRBAC model [25], an XML-based RBAC model supporting a large variety of temporal constraints on the use of roles by users. The key idea underlying such an approach is to associate with each role a set of preconditions for the use of roles. Each user verifying such preconditions is given permission to use the role; there is no need to grant these users an explicit permission for the role, thus simplifying the management of the UA relation (see Figure 3.2).

In X-GTRBAC, such preconditions are expressed against user credentials, which are encoded in SAML. In particular, by using the precondition language supported by X-GTRBAC, it is possible to condition the use of a role in a domain, referred to as the target domain, to the authorization of using the same role or even another role in another domain, referred to as the source domain. A user authorized to use a role r in the source domain can thus use a role r′ in the target domain, provided that the authorization to use r is a precondition for the use of r′. Assertions concerning the fact that a user can use a role r in a given domain are encoded by the source domain using SAML. In addition to accepting SAML assertions as input, X-GTRBAC also generates SAML assertions as a result of access control; therefore, whenever the X-GTRBAC instance at the target domain determines that a user can access a role, it generates an SAML assertion stating this fact. Such an assertion can then be used for accessing a role in another domain.

This type of role interoperability enhances decentralization and autonomy. Each domain can independently decide the preconditions that the users of another domain need to verify for gaining access to the local roles. Such preconditions can be different for users from different domains. Revoking the authorizations to use a local role from remote users is very easy, in that one only has to drop the preconditions concerning such users.

Even though X-GTRBAC represents an important approach to the problem of multidomain access control, several issues still need to be investigated, including anonymous accesses and delegation.

GEO-RBAC

The widespread deployment of location-based services and mobile applications, as well as the increased concern for the management and sharing of geographical information in strategic applications like environmental protection and homeland security, have resulted in a strong demand for spatially-aware access control systems. These application domains pose interesting requirements against access control systems. In particular, the permissions assigned to users depend on their position in a reference space. Users often belong to well-defined categories, and objects to which permissions must be granted are located in that space. Access control policies must grant permissions based on object locations and user positions.

As an example, consider a mobile application for the personnel and patients of a health care organization. Individuals are given a location-aware terminal with which they can request information services provided by an application server. The organization consists of individuals who have different functional roles (e.g., nurse, doctor, and patient). We can notice that, depending on the organizational context, the services available to users may differ based on the functional roles of users. For example, the services available to nurses may be different from those available to doctors, not simply because of the individual preferences but mainly because of organizational and functional reasons. Further, the availability of services may depend on the position of the requester. For example, a nurse may be allowed to request the record of a patient only when located in the department he or she has been assigned to. To deal with the requirements listed above, an access control model with spatial capabilities is needed. Since in location-aware applications users are often grouped in distinct categories, like nurse and doctor, RBAC represents a reasonable choice. However, conventional RBAC does not suffice to support such applications and needs to be extended with suitable constraints specifying location constraints, that is, constraints concerning the locations in which a given role can be accessed by a user. It is important to notice that locations can be physical, that is, expressed as coordinates in the reference space, or logical, that is, expressed in terms of spatial objects (such as the city of Milan, the West Valley Hospital) that have a semantics that are relevant to the specific application domains. When dealing with location-based applications it is also important to take into account relevant standards for the representation of spatial objects; one such standard is the one by the Open Geospatial Consortium [26].

GEO-RBAC is a recently developed model that directly supports such types of location constraints. It is based on the notion of spatial role that is a geographically-bounded organizational function. The boundary of a role is defined as a geographical feature, such as a road, city, or hospital, and specifies the spatial extent in which the user has to be located in order to use the role. Besides a physical position, obtained from a given mobile terminal such as a global positioning system–based vehicle tracking device or a cellular phone, users are also assigned a logical and device-independent position representing the feature in which the user is located. Logical positions can be computed from real positions by using specific mapping functions and can be represented at different granularities, depending on the spatial role played by the user. If the user is located inside the spatial boundary of the role that has been selected (activated) during the session, the role is said to be enabled. To specify the type of spatial boundary of the role and the granularity of the logical position, GEO-RBAC has introduced the concept of spatial role schema. Spatial roles are specified as instances of role schemas.

As RBAC, GEO-RBAC encompasses a family of models:

• Core GEO-RBAC includes the basic concepts of the model, thus the notion of spatial role, role schema, real/logical position, and activated/enabled role.

• Hierarchical GEO-RBAC extends the conventional hierarchical RBAC by introducing two distinct hierarchies: one over role schemas and one over role instances.

• Constrained GEO-RBAC supports the specification of separation of duty (SoD) constraints for spatial roles and role schemas. Since exclusive role constraints are important to support the definition and maintenance of access control policies in mobile contexts, SoD constraints are extended to account for different granularities (schema/instance level), dimension (spatial/nonspatial), and different verification time (static, dynamic at activation time, dynamic at enabling time). The resulting set of constraints developed for GEO-RBAC represents the first comprehensive class of constraints for spatially-aware applications.

Even though GEO-RBAC provides a comprehensive model for location-based access control, many issues still need to be investigated, such as architectural issues and session management.