YagueMana-sacmat05

7/27/2019 YagueMana-sacmat05

1/23

A Semantic-based Access Control Model*

Mariemma I. Yage, Antonio Maa{yague, amg}@lcc.uma.es

Computer Science Department

University of Mlaga. Spain.

Abstract.Very dynamic environments with high volume of heterogeneous data, like semi-structured data systems, DRMrepositories, digital libraries, web services, distributed object systems, etc. require more flexible constructions for the ex-

pression and management of access control systems than those provided by traditional access control models. This paperpresents the Semantic Access Control model; a new access control model that solves the problems of other access control

models when applied to these environments. This model provides a high level of interoperability, scalability, flexibility,

adaptability, applicability. It ensures semantic policy soundness, eases administration and avoids the registration phase.

1 Introduction

When security requirements for distributed applications are considered, authorization often emerges as a central element in

the design of the whole security system. Many other security requirements depend on the flexibility, trustworthiness and ex-

pressiveness of the authorization scheme. On the other hand, access control is the mechanism that allows resource owners

to define, manage and enforce the access conditions that apply to each resource [1]. These two concepts are very closely re-

lated because authorizations are usually the basis for the access decision in access control systems.

The concepts upon which an access control model is defined determine the flexibility of the model to be applied in differ-

ent environments and systems. Traditional access control models have been designed to solve the access control problem in

some specific scenarios and applications. Let us briefly review these models and their target environments:

o Discretionary Access Control (DAC) was designed for multi-user systems and databases. In this environment, a lim-

ited number of previously-known users are considered. Changes are not very frequent and all resources are under

control of a single authority. Consequently, DAC policies are based on user identity and a series of access rules that

express what users can and cannot do [2].

o Mandatory Access Control (MAC) originated in military environments, where the number of users can be high, but

an static and linear hierarchy of users can be established. In this case the model is based on a hierarchy of security

levels. MAC policies are based on the assignment of security levels to users and resources, defined by a central au-

thority [3].

* Work partially supported by Spanish Ministry of Science and Technology. Project TIC2002-04500-C02-02


2/23

o Role-Based Access Control (RBAC) was designed to overcome the problems of the previous models when applied to

a more open environment such as corporate information systems. In these environments, users are usually classified

following a tree-like hierarchy, established according to the position (role) of the user. RBAC policies define what

roles can access each resource [4].

Among these models, RBAC is commonly accepted as the most appropriate paradigm for the implementation of access

control in complex scenarios. RBAC can be considered a mature and flexible technology. Numerous authors have discussed

its properties and have presented different languages and systems that apply this paradigm [4-7].

However, very dynamic environments with high volume of heterogeneous data, like semi-structured data systems, DRM

repositories, digital libraries, web services, distributed object systems, etc. require more flexible constructions for the expres-

sion of access control policies. In RBAC the s tructure of groups is defined by the security administrator and it is usually

static. Although the grouping of users can suffice in many different situations, it is not flexible enough to cope with the re-

quirements of more dynamic systems where the structure of groups can not be anticipated by the administrators of the ac-

cess control system. In these scenarios new resources are incorporated to the system continuously and each resource may

possibly need a different group structure and access control policy. Furthermore, the policy for a given resource may change

frequently.

Furthermore, traditional access control schemes are not suitable for scenarios where the local registration and authoriza-

tion of users is not appropriate or with a very large number of registered users. In these systems it is not practical to keep ac-

cess and authorization information for each user, for scalability reasons.

As a consequence, we can conclude that a different approach is required in order to solve the scalability problems of

these systems, to facilitate access control management and to provide means to express access conditions in a natural and

flexible way. Our diagnostic is that the main problem with role based access control in this type of heterogeneous, open and

dynamic environments is that the model is built on three predefined concepts: user, role and group. The definition of

roles and the grouping of users can facilitate management, especially in corporation information systems, because roles and

groups are easily identifiable and fit naturally in the context of the organizational structures of the companies. However,when applied to some new and more general access control scenarios, these concepts are somewhat artificial. There are situ-

ations that are not well- handled by this model. For instance, consider the case of a very dynamic system where users attrib-

utes (and therefore, the membership of the user to a given role) changes frequently. A solution is to determine role member-

ship dynamically, but it requires an important effort to do so. Furthermore, in RBAC, a role must be defined for each different


3/23

set of access criteria required by the group of resources controlled. This means that when the number of resources and the

heterogeneity of access conditions is very high, the administration of RBAC systems becomes very complex. In fact, taken

to the limit, if each resource can be accessed by a different group of users, the number of roles can reach the number of re-

sources and require the explicit association of users to all roles (resources) they can access.

We believe that a more general approach is needed in order to be used in these new environments. For example, in the re-

ferred situations, groups are an artificial substitute for a more general tool: the attribute. In fact, groups are usually defined

on the basis of the values of some specific attributes (employer, position, ). Some attributes are even built into most of the

current access control models. This is the case of the userelement; the identity is just one of the most useful attributes, but

it is not necessary in all scenarios and, therefore, it should not be a built-in component of a general model.

Finally, access control models must take into account that the creation and maintenance of access control policies is a dif-

ficult and error prone activity. Therefore, we consider that access control models must be designed to facilitate and guaran-

tee the correct administration of the system.

The Semantic Access Control (SAC) model [8] provides an appropriate solution to aforementioned problems, especially

for heterogeneous, distributed and large environments. As we will show later, the flexibility of the SAC model allows it to

easily simulate other models such as MAC, DAC or RBAC.

2 Fundamentals of the Semantic Access Control Model

Most of current access control schemes base their authorization approaches on locally-issued credentials that are based on

user identities. This type of credentials presents many drawbacks. Among them we highlight: (a) they are not interoperable;

(b) the same credentials are issued many times for each user, what introduces management and inconsistency problems; (c)

credentials are issued by the site administrator, however, in most cases, the administrator does not have enough information

or resources to establish trustworthy credentials; and (d) they are dependent on user identity. However, in practice, it is fre-

quent that the identity of the user is not relevant for the access decision. Sometimes it is even desirable that the identity is

not considered or revealed. Furthermore, in systems based on identity, the lack of a global authentication infrastructure (a

global Public Key Infrastructure, PKI) forces the use of local authentication schemes. In these cases, subscription is required

and users have to authenticate themselves to every accessed source. To solve the aforementioned problems, single-sign-on

mechanisms are becoming popular [9]. Although these mechanisms represent an improvement, they do not enable interoper-


4/23

ability maintaining the diversity. The reason is they are based on federation of sources and all federated sources must agree

on a homogeneous access control scheme. Additionally, credentials remain local, not to a site, but to a set of them.

On the other hand, digital certificates can securely convey authorizations or credentials. Attribute certificates bind attrib-

utes to keys providing means for the deployment of scalable access control systems in the scenarios that we have depicted.

These authorizations are interoperable and represent a general and trustworthy solution that can be shared by different sys-

tems. Taking into account security, scalability and interoperability, the separation of the certification of attributes and access

control management responsibilities is widely accepted as a scalable and flexible solution. In this case, the access control

system needs to be complemented by an external component: the Privilege Management Infrastructuire PMI [10]. The main

entities of a PMI, known as Source of Authorizations (SOAs), issue attribute certificates. Usually, each SOA certifies a small

number of semantically related attributes. This scheme scales well in the number of users and also in the number of different

factors (attributes) used by the access control system. The flexibility of this model is such that it can easily represent com-

plex access conditions that are very difficult to express in other models.

With this approach, each access control system selects the SOAs to trust and which combination of attributes to use. Be-

cause they are separate systems, a mechanism to establish the trust between the access control and the PMI is required. In

this work, we propose the use of metadata to describe the PMI as the key to achieve the necessary interoperability.

On the other hand, when discussing how to establish the access conditions applicable to a particular resource, two main

approaches must be considered: (i) conditions are established on the basis of the location of the resources or, (ii) conditions

are based on the properties of the resources. The fact is that conditions and restrictions of access depend naturally on the

semantic properties of the target resource that are neglected in structure-based approaches. Therefore, an approach based

on semantic descriptions of the contents is much more flexible and natural. Moreover, it is easy to incorporate structure-

based requirements in the semantic model. Additionally, the s tructure is much more volatile than the semantics. The incom-

patibility between the structure required for the application domain and the ones that match the security requirements con-

firms that structure-based approaches are not able to represent these situations in a natural way.

Another drawback of structure-based approaches is that the number of policies becomes very large. In fact, these ap-

proaches usually imply the definition of several policies for each resource. Positive and negative authorizations are used in

these cases to facilitate the definition of simple policies and to reduce the number of policies. The price to pay is the intro-

duction of ambiguities, which in turn requires the definition of conflict resolution rules. Consequently, the administration of

the system becomes complex and difficult to understand increasing the chance of producing incorrect policies.


5/23

The access control model developed has been called Semantic Access Control (SAC) because semantics are the basis of the

access conditions and its design follows a semantic approach. The SAC model is based on the semantic properties of the re-

sources to be controlled, properties of the clients that request access to them, semantics about the context and finally, se-

mantics about the attribute certificates trusted by the access control system.

The semantic-based and modular approach adopted in SAC, facilitates the definition and management of policies avoiding

the use of positive and negative authorizations. Tools provided to support the policy specification, composition and valida-

tion also serve this objective [11]. The Semantic Access Control (SAC) model has been implemented on the basis of a lan-

guage to specify the access control criteria and the semantic integration of an external authorization entity.

1.1 The Semantic Policy Language, SPL

SPL XML-Schema based policy definition language is designed to specify policies in a simple way, enabling a high level of

expressiveness and an efficient evaluation.

Usual components of access policies include the target resource, the conditions under which access is granted/denied

and, sometimes, access restrictions. As opposed to other languages, specifications in SPL do not include references to the

target object. Instead, a separate specification called Policy Applicability Specification (PAS) is used to relate policies to ob-

jects dynamically when a request is received. Both SPL Policies and PAS use semantic information about resources, included

in SRRs, and other contextual information documents.

SPL Policies and PAS can be parameterised allowing the definition of flexible and general policies, thus reducing the num-

ber of different policies to manage. Parameters, which can refer to complex XML elements, are instantiated dynamically from

semantic and contextual information.

Additionally, policies can be composed importing components of other policies without ambiguity. This compositional

approach allows us to define the abstract meaning of the elements of the policies, providing a mechanism to achieve abstrac-

tion, which also helps in reducing the complexity of management. The schema for SPL specifications is represented as a set

of XML-Schema templates that facilitate the creation of these specifications, allowing their automatic syntactic validation.

Figure 3 shows the conceptual model of the SPL language. Detailed models of each component are included in Appendix

A. SPL policies can include components defined locally as well as imported elements. The ability to import elements enables

the modular composition of policies based on the XPath standard. An SPL Policy is composed of a set of access_Rule ele-

ments. Every access_Rule defines a particular combination of attribute certificates required to gain access, associated with


6/23

an optional set of actions (such as Notify_To, Payment and Online_Permission) to be performed before access is granted. In

this way provisional authorization or PBAC[12] is enabled in SPL.

Imported ElementLocal Element

SPL Policy

PAS

Context

SRR

Property

Resource

Parameter

0..*

0..1corresponds

1..* 1..*

relates

0..*

1..* 1

relates

0..*0..1

extracted from

1..*

0..*

described by 1..*

0..*0..*

1..*

0..*

0..1extracted from

Fig. 3. Conceptual model of the SPL Language

1.2 The Semantic Description of the Sources of Authorization

Based on asymmetric cryptography, digital certificates are used to bind a public key to some information. Identity certific-

ates (a.k.a. public-key certificates) are the most common type of digital certificates in use. They bind identity information to

keys. On the other hand, attribute certificates [10] bind attributes to keys. Among other applications, they provide means for

the deployment of scalable and flexible access control schemes, since access conditions are expressed in terms of sets of at-

tributes instead of users or groups. Users must possess attribute certificates attesting that they meet the requirements. Op-

posed to traditional access control schemes, a high number of users and attributes do not degrade performance and manage-

ability of this solution.

One of the main advantages of attribute certificates is that they can be used for various purposes. They may contain

group membership, role, clearance, or any other form of authorization. A very essential feature is that attribute certificates

can securely transport authorization information in distributed applications. This is especially relevant because, through at-

tribute certificates, authorization information becomes mobile, which is highly convenient for scenarios such as those con-

sidered in this work. This mobility provides the foundation for a better alternative to actual Single Sign-On schemes.

The mobility feature has been used in applications since the publication of the 1997 ITU-T X.509 Recommendation.

However, it has been used in a very inefficient way. That Recommendation introduced an ill-defined concept of attribute cer-


7/23

tificate that was not independent of the identity certificate. To be more precise, when using that solution, the change of priv-

ileges indirectly forces a costly revocation of the identity related information. Moreover, that solution does not solve delega-

tion and impersonation issues, which are especially relevant in many applications. The ITU-T 2000 Recommendation

provides a more suitable solution because it clearly defines a framework, a Privilege Management Infrastructure, or PMI,

where identity and attribute certificates, although related, can be independently managed.

The objective of a PMI is to provide attribute certification services. It is then reasonable to expect that the PMI includes

different certification authorities (SOAs), each one with a well-defined certification domain. That is, each SOA should be au-

thoritative for a limited set of attributes and users. Ideally, each attribute would be certified only by one SOA. This raises the

issue of the interoperability of the attribute certificates. Suppose John Doe is an authorized broker at the Chicago Board of

Trade. Then John will have two separate certificates: an identity certificate attesting his identity information and an attribute

certificate attesting he is an authorized broker at the Chicago Board of Trade. Both certificates can be related, for instance, by

including the serial number and/or hash value of the identity certificate in the attribute certificate.

If we focus simultaneously on security, scalability, interoperability and mobility, it is advantageous to separate the re-

sponsibilities of access control management from certification of attributes. There are some reasons for this statement. In

centralized access control schemes each application requires its own database or directory of authorizations, which must be

administered and maintained. The result is that for every user, identities and profiles must be entered multiple times and syn-

chronized dynamically, increasing the operating costs associated with change management and making the process cumber-

some. However, the same users attributes are often used in multiple access decisions in different systems. We can conclude

that users attributes can be shared by all access control systems, while access criteria are specific.

Suppose now that our friend John Doe is also member of the Chicago Siesta Club (CSC), a public library, Greenpeace, etc.

If centralized access control schemes are used in these institutions, each one will have to locally register the different attrib-

utes of John Doe that are applicable to their access control policies. For instance, if the CSC has a discount for Greenpeace

members then it is necessary that the membership of John to Greenpeace is recorded in the local database of users of the

CSC. How can CSC be sure that John is member of Greenpeace? What if John leaves Greenpeace? How does CSC know

about this? On the contrary, if the attribute certification function is separated then access control systems responsibilities

are limited to establishing the local access control policies, making the system simpler, more dynamic and flexible, and more

secure. Obviously, this approach requires that the access control system is complemented by an external component provid-

ing certification functions. Precisely, the PMI is that component.


8/23

A consequence of the separation of access control and authorization functions (now provided by the PMI) is that the ac-

cess control administrators do not have control over some factors that are used in their access control systems. Con-

sequently, a mechanism to establish the trust between these administrators and the PMI is required. We have addressed this

problem using semantic information about the certifications issued by each SOA. This assists the security administrators in

the creation and semantic validation of access control policies.

In our approach, every SOA produces and digitally signs a set of Source Of Authorization Descriptions (SOADs) that ex-

press the semantics of the attribute certificates it issues [13]. These metadata documents describe the different attributes cer-

tified by a SOA, including names, descriptions and relations of attributes. SOADs are used to establish the trust between the

PMI and the access control systems. They convey the information needed by the access control system to understand the

semantics of the attribute certificates, which is essential in order to take appropriate access decisions. The information con-

tained in SOADs is also essential for the semantic validation of the policies, enabling the detection of semantically incom-

plete (or incorrect) policies. In fact, the set of SOADs represents the semantic description of the PMI. Full integration of the

PMI can be achieved transparently for the rest of the system based on this description.

3 Formal Model of the Semantic Access Control

In this section we propose a formal model of SAC, as the basis for the processing of the Semantic Policy Language (SPL)

specifications. The basic concepts upon which this formal model is constructed are defined as follows:


9/23

Definition 1. A target is any entity that may hold properties. In the SAC model, a target can be a client or a re-

source and properties are represented as attributes.

Definition 2. Attributes represent properties about targets. An attribute is represented by a triplet (p,o,v) wherep is

a property name, o is a logical operator and v is a value. For instance, the property of being adult in

Spain is (age, >, 18). The fact that a target tholds theattribute a is denoted as a(t).

Definition 3. A set of attributes, in the followingAttributeSet, represents an unordered collection of attributes.

Definition 4. A Source of Authorization, a.k.a. SOA, is a certification entity responsible of issuing attribute certific-

ates attesting certain properties about targets. Each SOA has a certification domain, i.e. a set of tar-

gets and properties that can be certified by this SOA. For instance, the SOA of an university may is-

sue certificates related to the enrollment of its students in courses, but not about their marital status.Likewise, it can not issue certificates related to the enrollment of students from other universities.

Definition 5. An attribute certificate is a sentence signed by a SOA attesting a(t) , i.e. attesting that target t

holds the attribute a. It is denoted as a,t. We assume, without loss of generality, that the holdert

of this attribute certificate will be identified by its public key1.

Definition 6. Let T be the set of all targets in the certification domain of. An attribute certificate class, denoted

as a, represents the semantics of the set of all instances (attribute certificates) a,t where tT.

Definition 7. The relationships among different attribute certificate classes are satisfied by all their instances.

Therefore, let R be a relationship among attribute certificates classes, then

(a R b) ( t1 T,, t2 T, a,t1 R b,t2)

Definition 8. A SOA rule is a sentence related to a SOA stating that two attribute classes a and b are in-

terrelated. A SOA rule is expressed as

a relational_operatorb

1 In asymmetric encryption schemes each user has a pair of related keys. One of these keys, the Public Key, is publicly distrib-

uted while the other one, the Private Key, must be kept secret. Public Key's are included in digital certificates, so that other users can

verify their authenticity.


10/23

Note that a SOAD can only contain rules to state facts about internal certificates (certificates issued by the corresponding

SOA). It can include relations between internal and external certificates, but these relations must be interpreted to be direc-

tional.

Definition 9. A SOA description, orSOAD, is the set of all SOA rules describing aSOA. The SOAD describing is

denoted as SOAD.

Definition 10. Let a and b be two attribute certificates classes. Let denote a given set of facts specified af-

terwards. We say a implies b, denoted as a b, if a SOA rule or a series of them exists

in SOAD such that b is logically implied by a. It is written as:

SOAD, a b

That is, from the attribute certificate class a, applying the rules expressed in the SOAD of, we can deduce the attribute

certificate class b

Definition 11. Let a and b two attribute certificates classes. We say a excludes b, denoted as a

b, if there exists a SOA rule or a series of them in SOAD such that:

SOAD, a b

That is, from the attribute certificate class a, applying the rules expressed in the SOAD of, we can deduce that b

does not hold.

Definition 12. Let a y b two classes of attribute certificates. We say a is inconsistent with b, denoted

as a b, ifa excludes b and/orb excludes a, that is:

SOAD, a b and/or SOAD, b a

Definition 13. Let a and b two classes of attribute certificates. We say a is consistent with b, denoted

as a b, if no SOA rule or series of them exists in SOAD such that:

SOAD, a b

and no SOA rule or series of them exists in SOAD such that:

SOAD, b a


11/23

4 Semantic Validation of Policies

The creation and maintenance of access control policies is a difficult and error prone activity. SAC includes components for

the automated validation of policies at different levels. The syntax of SPL policies is validated against the corresponding

XML Schema. We have developed a specific Semantic Policy Validator (SPV) as part of the Policy Assistant component to

perform different types of semantic validation. These validations are supported by the semantic information defined by

means of XML metadata.

SPV allows policies to be validated in the context where they will be applied. By using semantic information about the

context, the administrator is able to include relevant contextual considerations in a transparent manner.

The semantics of the policies depend heavily on the semantics of the attribute certificates. In the SAC access control

model the SOAD metadata model conveys the semantics of the attribute certificates providing semantic information that will

be essential in the process of access decision. The semantic information about the attribute certificates issued by each SOA

also assist the security administrator through the process of specification of the access control policies, as it conveys the

meaning of each attribute. Additionally, the semantic information represented by the SOAD model enables the automatic de-

tection of inconsis tent policies, through the SPV tool developed with this objective. The SPV makes logic inference process -

es using the rules defined in the SOAD documents.

The ability to perform a semantic validation of access control policies is an essential design goal of the SAC model. Both

the SPL language and the SOAD documents have been designed to serve this objective. The semantic validation ensures

that the policies written by the security administrator produce the desired effects. The SPV can perform the following types

of validations, which are described in detail in Appendix B:

1. Test Case Validation: Given a request to access a resource and a set of attribute certificates, this algorithm outputs the

sets of attribute certificates needed for accessing that resource. Most of times, this feature will be used to check that a set

of attribute certificates is incompatible with the access criteria for that resource. For instance, the administrator of our uni-

versity can use this validation to guarantee that it is not possible for a student to access a given resource (i.e., documents

containing marks). During the validation process, the SPV generates the sets of attribute certificates that are not excluded

by the input set, and checks the generated ones against all possible combinations of attribute certificates that grant ac-

cess to the resource.


12/23

2. Access Validation: Given a request to access a resource, this algorithm outputs the sets of certificates that grant access to

that resource. For this validation process, the SPV generates the policy for the resource and all sets of attribute certifi-

cates equivalent to those required by the policy.

3. Full Validation: The goal of this process is to check which resources can be accessed given a set of attribute certificates.

Therefore, SPV generates the policy for each resource and, afterwards, all attribute certificates that can be derived from

the input set of attribute certificates. Finally, it informs of every resource that can be accessed using the input attribute

certificate set.

5 Related Work

Recent literature in the area of access control for distributed heterogeneous resources from multiple sources shows the use

of attribute certificates and PMIs. Firstly, we highlight two research projects, Akenti[14] and Permis [15]. Akenti Project pro-

poses an access control system to restrict access to distributed resources controlled by multiple stakeholders. The require-

ment for the stakeholders to trust the rest of the servers in the network, as well as some security vulnerabilities related to the

existence of positive and negative use-conditions, are the main drawbacks of Akenti.

Two relevant proposals for access control to XML documents are the Author-X system [16] and the FASTER project [17].

They differ with our proposal in that both systems have been specifically developed for XML documents, opposite to the

general definition of resource in this work. However, they share some features with our solution. While AuthorX policy lan-

guage uses Data Type Definitions (DTDs) [18], our Semantic Policy Language (SPL) and FASTER use XML-Schema [19], the

W3C successor of DTDs. Author-X is based on credentials that are issued by the access control administrator. Therefore, in

practice, each credential will be useful only for a single source, limiting interoperability. A direct consequence of this ap-

proach is that users must subscribe to sources before they can access their contents. Opposite to this, in our Semantic Ac-

cess Control Model (SAC) we have semantically integrated a Privilege Management Infrastructure that will be the respons -

ible of issuing digitally signed attribute certificates.

Different XML-based languages have been proposed for access control, digital rights management, authentication and

authorization. Although many similarities and interesting features can be found among them, some other features, such as

policy parameterisation and composition are not supported. Moreover, some features provided by those languages are not

appropriate in heterogeneous and dynamic scenarios. The most relevant is XACML [20], an OASIS standard that proposes


13/23

two XML-based languages to describe access control policies and access decision requests and responses. Although

XACML and SAC share some similarities, there are important differences, such as:

o In the XACML Specification the term attribute is used in place of the terms group and role. In SAC, the term attribute is

generic, and can be used to represent any kind of property of the access requester (application, web service, user) or

the resource to be accessed.

o Separate XACML policies can be combined into a single policy. XACML provides means to specify precise procedures

for combining the results of the evaluation of the basic policies. The rule-combining algorithm defines a procedure for

arriving at an authorization decision given the individual results of evaluation of a set of rules. Some predefined al-

gorithms are included for: deny-overrides, permit-overrides, first applicable and only-one applicable. Summarizing, policy

composition in XACML is limited to the combination of partial access decisions. On the other hand, SAC policies are

built on the basis of semantics of the access control criteria. Consequently, the composition of different access control

policies is performed on the basis of the semantics of these policies, allowing rich combination of access criteria, not

only of partial access decisions.

o Allocation of policies to resources in XACML is explicit and static. Opposite to this, SAC defines a mechanism for the

dynamic allocation of policies to resources, based on semantics of the latter.

o XACML provides facilities for content-based access when the information resource can be represented as an XML doc-

ument. SAC supports content-based naturally imposing no restriction on the format: every kind of resource (a physical

resource, a digital document with any format ) can have an associated document, describing its semantics.

o The architecture of XACML is one of its main contributions. XACML proposes a very flexible scheme based on the

definition of Policy Enforcement Points (PEPs), Policy Decision Points (PDPs), etc. The fully distributed and open ap-

proach of SAC makes possible that the inclusion of PEPs and PDPs does not require any modification on the SAC mod-

el. As with the case of XACML, SAC policies may be written and analyzed independently of the specific environment in

which they are to be enforced.

o Finally, the SAC model considers the execution of some actions during the enforcement of the access request, therefore

providing full support for Provisional-Based Access Control (PBAC). XACML only supports a predefined set of these

actions.

An additional advantage of SAC is that semantic and contextual validation of policies is made possible.


14/23

6 Conclusions and Future Work

RBAC is commonly accepted as the most appropriate paradigm for the implementation of access control in complex scenari-

os. However, very dynamic environments with high volume of heterogeneous data require more flexible constructions for the

expression and management of access control policies. Furthermore, traditional access control schemes are not suitable for

scenarios where the local registration and authorization of users is not appropriate As a consequence, we can conclude that

a different approach is required in order to solve the scalability problems of these systems, to facilitate access control man-

agement and to provide means to express access conditions in a natural and flexible way. Distributed authorization infra-

structures (PMIs) can be very useful for solving these problems, but in this case a mechanism to establish the trust between

the PMI and the access control system is required. Finally, access control models must be designed to facilitate and guaran-

tee the correct administration of the system.

The Semantic Access Control (SAC) model presented in this paper provides an appropriate solution to aforementioned

problems, especially for heterogeneous, distributed and large environments. The SAC model can easily simulate MAC, DAC

and RBAC models. To facilitate the definition and management of policies, we have taken an approach based on the modular

definition of policies that can be composed without ambiguity. The SPL language it is based on semantic properties about

the resources to be accessed, the PMI and the context. These semantics are used during the specification of access control

criteria, dynamic policy allocation, parameter instantiation and policy validation. Additionally, means for the integration of an

external PMI supported by semantic information about the certification entities have been proposed.

References

1. Samarati, P., de Capitani di Vimercati, S.: Access Control: Policies, Models, and Mechanisms. In FOSAD 2000. LNCS 2171, pp. 137- 196,

2001.

2. Baraani, A., Pieprzyk, J., Safavi-Naini, R.: Security In Databases: A Survey Study. http://citeseer.nj.nec.com/baraani-dastjerdi96secur-

ity.html. 1996.

3. Qian, X., Lunt, T.F.: A MAC policy framework for multilevel relational databases. IEEE Transactions on Knowledge and Data Engineer-

ing, 8(1):1-14. February 1996

4. Sandhu, R.S., E.J. Coyne, H.L. Feinstein, and C.E. Youman,Role-Based Access Control Models. IEEE Computer, 1996. 29(2): pp.

38-47.

5. Baldwin, R. W.Naming and Grouping Privileges to Simplify Security Management in Large Database. Proceedings of IEEE Com-

puter Society Symposium on Research in Security and Privacy, pp. 61-70, Oakland, CA, April 1990.

6. Osborn, S.; Sandhu, R.; Munawer, Q. Configuring Role-Based Access Control to Enforce Mandatory and Discretionary Access Con-trol Policies. ACM Transactions on Information and System Security, 3(2) pp. 85-106. 2000.

7. Sandhu, R.; Ferraiolo, D.; Kuhn R. The NIST Model for Role-Based Access Control: Towards a Unified Standard. Proccedings of the

fifth ACM Workshop on Role-based Access Control. pp. 47-63. 2000.

8. Yage, M.I., Maa, A., Lpez, J., Troya, J.M.:Applying the Semantic Web Layers to Access Control. Proc. Int. Workshop on Web

Semantics, Dexa 2003. IEEE Computer Society Press. September 2003.

9. Sundsted, T. With Liberty and single sign-on for all. The Liberty Alliance Project seeks to solve the current online identity crisis,Available http://www.javaworld.com/javaworld/jw-02-2002/jw-0215-liberty_p.html, 2002.


15/23

10. ITU-T Recommendation X.509: Information Technology - Open systems interconnection The Directory: Public-key and attributecertificate frameworks, Available ht tp://www.itu.int/rec/recommendation.asp?type=folders&lang=e&parent=T-REC-X.509

11. Yage, M.I. Modelo basado en Metadatos para la Integracin Semntica en Entornos Distribuidos. Aplicacin al Escenario deControl de Accesos. Ph.D. dissertation. Computer Science Department, University of Mlaga.

12. Kudo, M., Hada, S. XML Document Security based on Provisional Authorisation. 7th ACM Conference on Computer and Commu-

nications Security. 2000.

13. Yage, M.I., Maa, A., Lpez, J., Pimentel, E., Troya, J.M. A Secure Solution for Commercial Digital Libraries. Online InformationReview Journal, 27(3), 147-159. 2003.

14. Thompson, M., et al., Certificate-based Access Control for Widely Distributed Resources, Eighth USENIX Security Symposium.1999.

15. Chadwick, D. W., An X.509 Role-based Privilege Management Infrastructure, Global Infosecurity. 2002.16. Bertino, E., Castano, S., Ferrari, E. Securing XML documents with Author-X. IEEE Internet Computing, 5(3):21-31, May/June 2001.17. Damiani, E., De Capitani di Vimercati, S., Paraboschi, S., Samarati, P.A Fine-Grained Access Control System for XML Documents.

In ACM Transactions on Information and System Security (TISSEC), vol. 5, n. 2, May 2002, pp. 169-202.18. World Wide Web Consortium. Guide to the W3C XML Specification ("XMLspec") DTD, Version 2.1.

http://www.w3.org/XML/1998/06/xmlspec-report.htm19. World Wide Web Consortium,XML-Schema, http://www.w3.org/XML/Schema20. OASIS. XACML 1.1 Specification Set. Available http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xacml. 2003.


16/23

Appendix A. Conceptual models of the SAC components

Conceptual model of SPL

ImportedAccessRules

Attribute

+AttributeDescription[0..1]+AttributeID[0..1]

+Equivalence[0..1] = "Enabled"

+Predicate[0..1] = "Equals"...

ImportedAccessRule

ImportedAttributeSet

LocalAccessRule

LocalAttributeSet

LocalAccessRules

ImportedAttributeValue

ImportedAttributeName

ImportedSOA_ID

ImportedPolicy

LocalAttributeValue

AttributeName

Policy

+PolicyDescription[0..1]

+PolicyID[0..1]

LocalAttributeName

AttributeValue

AttributeSet

-AttributeSetDescription

-AttributeSetID-AttributeSetName

LocalPolicy

AccessRule

+Name[0..1]

+Public[0..1] = "true"

+ValidFrom[0..1]

+ValidUntil[0..1]

SOA_ID

LocalSOA_ID

AccessRulesParameter

Import

+URL+XPath

Action

0..*

0..* 1..*

1..*

1..*


17/23

Conceptual model of PAS

Condition

+Predicate[0..1] = "Equals"

Policy

+PolicyDescription[0..1]

+PolicyID[0..1]

PAS

ActualParameter

Object

FormalParameterObjectLocation

PropertyName PropertyValue

Instantiation

Operation

Parameter

0..*

0..*

0..*

0..*

Conceptual model of SRR

Property


PropertyName PropertyValue

SRR

Resource

-XPath

1..*


18/23

Conceptual model of SOAD

SOAAttribute


...

AttributeValueAttributeName

ACRelationsSOA_ID ACDeclarations

SOA_ID

SOAAttributeSet

SOARule

Relation

SOAD

0..1

1..*

21..*

1..*


19/23

Appendix B. Pseudo-code of the semantic validation algorithms

Test-case Validation algorithm

Input:Resource, resource requested for the accessCCA, set of Attribute Certificates

Output:Display Report

Process:P= Generate_Policy (Resource)

(* returns a composed and instantiated policy from all policies defined for Re-source *)L = Generate_Compatible (CCA)

(* returns a list of sets of attribute certificates compatible with CCA*)WHILE L.notEmpty() DOCA = L.first

L = L.nextReport(CA, P)ENDWHILE

Report algorithm

Input:CCA, set of Attribute CertificatesP, Composed and instantiated policy

Output:Display Report

Process:FOR EACH AccessRule IN PFOR EACH AttributeSet IN AccessRuleIF AttributeSet CCA THENWrite(Access granted by the rule , Accessrule.Name, AttributeSet: , At-tributeSet.Name,With conditions to execute the Actions: , AccessRule.Action)

ENDIFENDFORENDFOR


20/23

Generate_Compatible_List algorithm

Input:

CCA, original set of Attribute CertificatesTrustedSOADs, SOADs trusted by the administrator

Output:

CIC, set of classes of Attribute Certificates consistent with the input CCAProcess:

CIC= FOR EACH bi IN TrustedSOADs DOIF (TrustedSOADs, CCA bi) THENCIC= CIC {bi}

ENDIFENDFORRETURN (CIC)

Generate_Compatible algorithm

Input:

CCA, original set of classes of Attribute CertificatesOutput:

LIC, List of Sets of classes of Attribute Certificates consistentwith the input CCA

Process:

LIC= Empty_List()Let be Compti = Generate_Compatible_List(CCA)

(* We generate list of certificates not excluded by CCA *)FOR EACH bj IN Compati DOIF (bj CCA) THEN

Let be Incompat={ I CCA / TrustedSOADs, I bj}(*Incompat: list of Ik where Ik is a subset of CCA certificates which areincompatible with b

j *)

IF Incompat THENFOR EACH Ik IN IncompatLIC.ADD(Generate_Compatible((CCA Ik) {bj})

ENDFORELSE (* We add one compatible *)

CCA= CCA {bj})ENDIF

ENDIFENDFORLIC.Add(CCA)RETURN (LIC)


21/23

Access Validation algorithm

Input:

Resource, resource requested for the accessOutput:

CAExpression, expression of attribute certificates joined by AND and OR operatorsProcess:P= Generate_Policy (Resource)

(* returns a composed and instantiated policy from all policies defined for Re-source *)CAExpression= Generate_CAExpr(P)Generated= Generate_Acceptable_Certificates(Attribute,Generated))CAExpression.Reduce ()

(* Morgan laws to reduce expressions*)RETURN (CAExpression)

Generate_CAExpr algorithmInput:P, Policy for the resource

Output:CAExpression, expression with combinations of attribute certificates of the poli-cy P.

Process:CAExpression= FOR EACH AccessRule IN PFOR EACH AttributeSet IN AccessRuleComb= FOR EACH Attribute IN AttributeSetComb.Addr_AND(Attribute)ENDFORCAExpression.Add_OR(Comb)

ENDFORENDFORRETURN (CAExpression)


22/23

Generate_Acceptable_Certificates_Attr algorithm

Input:Attribute, attribute from which we are looking for compatible attributes withGenerated, set of attributes yet generated

TrustedSOADs, SOADs trusted by the administratorOutput:CAExpression, expression with combinations of attribute certificates acceptedadditionally to the input ones (we can derive the input attributes from these)Generated, set of attributes yet generated

Process:(* A SOA rule is a sentence by a SOA stating the relationship between two

classes of attributes a and b: a logical_operator b *)CAExpression= CAExpression.AddOR(attribute)Generated = Generated {attribute}FOR EACH SOARule IN TrustedSOADs

IF attribute SOARule.BODY() THEN

CAExpression.AddOR(Generate_Aceptable_Certificates(SOARule.HEAD(), Gener-ated))

ENDIFENDFORRETURN (CAExpression)

Generate_Acceptable_Certificates algorithm

Input:CAExpression, expression with combinations of attribute certificatesGenerated, set of attributes yet generated

Output:CAExpression, expression with combinations of attribute certificates acceptablebesides the input ones (i.e. they allow the derivation of the input attributesfrom them)Generated, set of attributes yet generated

Process:FOR EACH Attribute IN CAExpressionIF (Attribute.Equivalence) AND (Attribute Generated) THEN

CAExpression.SustituteNodes(Attribute,Generate_Acceptable_Certificates_Attr(Attribute,Generated))ENDIF

ENDFORRETURN(CAExpression)


23/23

Full Validation algorithm

Input:

CCA, set of attribute certificatesOutput:

Display reportProcess:L= Generate_Derived(CCA)

(* returns a set of attributes derived from input CCA*)FOR EACH Resource DOP= Generate_Policy(Resource)Report(L,P)

ENDFOR

Generate_Derived algorithm

Input:CCA, set of attribute certificatesTrustedSOADs, SOADs trusted by the administrator

Output:CIC, set of classes of attribute certificates which we can derive from CCA

Process:CIC= CCADerived = { I / TrustedSOADs, CIC I }WHILE Derived CIC DO

CIC = CIC DerivedDerived = { I / TrustedSOADs, CIC I }

ENDWHILERETURN (CIC)

YagueMana-sacmat05

Documents

Transcript of YagueMana-sacmat05