Meta Model Based Integration of Role-Based and Discretionary Access Control Using Path Expressions

Transcription

1 Meta Model Based Integration of Role-Based and Discretionary Access Control Using Path Expressions Kathrin Lehmann, Florian Matthes Chair for Software Engineering for Business Information Systems Technische Universitaet Muenchen {lehmannk, Abstract Business applications have to deal with two types of access control models: the role-based and the discretionary access control model. The main contribution of this paper is that both data models are unified in a single description language. Starting from a meta model of an object oriented data model and a simple service model this paper shows how to describe and integrate access control needs in common business applications using an authorization model based on path expressions. These path expressions can be used to construct set-oriented queries for access control decisions derived from the data model of the application. Throughout the paper one example shows the expressive power of this authorization model.. Introduction Reliable authentication and authorization mechanisms are the two basic requirements that make up secure systems. By means of authentication the identity of the calling subject is verified. Entities whose identity can be verified are also called principals. Authorization procedures allow controlled access to restricted system resources. The calling subject must hold the permissions applicable to the request made in order to access restricted resources. This paper is about authorization. Access control systems are described by subjects, objects and actions. A permission is the ability to perform an action on an object. Some synonyms for permission are right, privilege, entitlement and authorization. Objects for which permissions are requested are called targets. In the simplest case granting permission to a subject only depends on the action, target and subject itself. More complex access control requests may need to know additional information like the state of the target object of other related objects within the system. Subjects are the active elements within a system; they are also called initiators or requestors. Objects represent the passive elements; they are resources on which protected operations the actions are invoked. Actions may have side-effects. Therefore, the invocation of access restricted operations should be considered a transaction that is either executed as a whole unit or not at all. This is to protect the integrity of the system and the resources administered herein at any time. Here, a transaction does not incorporate all ACID properties. Consistency and durability are not considered. Within business information systems, the rolebased access control (RBAC) model is most widely used. In RBAC, permissions on objects are grouped into roles. These roles are then assigned to subjects. In order to successfully execute an action on an object the requesting subject needs to have one or more roles activated that allow the execution of this action. There exists a proposed standard for this access control model []. The highest possible security of an RBACbased system is reached if the principle of least privilege is implemented. Therefore subjects should be able to surrender all but the minimal set of roles that enable the execution of the requested action(s). In some business information systems, e.g. community software, it is desirable to leave some access control decisions to the discretion of the owner of the respective resource, so that (s)he may decide which other subjects may impose which actions on the owned resources. This model is called discretionary access control (DAC) model.

2 In most business applications, both kinds of models are used in a mixed fashion. To unify administration tasks, both models have to be described in a common way. A naive way to do this is by establishing for every subject a separate role which represents the rights of ownership to owned resources. But this procedure produces a large number of roles that encapsulate only one subject, namely the owner of the resource for whom this role was created. In this paper, a different approach is taken. Access control decision functions are represented by paths in a data model. The paper is structured a follows. In the next chapter some related work is referenced. In chapter 3 the meta data model used as a basis for constructing path expressions for access control is introduced. Chapter 4 gives an example data model that is used throughout this paper. Chapter 5 introduces a simple service model that is assumed for this work. Chapter 6 is the main contribution of this paper. It explains an access control model based on path expressions. Chapter 7 gives a short example applying the access control model to the example introduced in chapter 4. The paper ends by giving a conclusion and hints on future work. 2. Related work As there exist many publications already on access control models and implementations the reference list only shows some major works that are relevant in the area of business applications. One example is the extensible Access Control Markup Language, in short: XACML, which is an OASIS standard currently in version.0 [2]. XACML is a powerful description language for expressing security policies in distributed systems by means of a standardized XML-format. XACML consists of a core specification and some profile extensions for special needs such as role-based access control or access to hierarchical resources. However, due to the hierarchical format of XML-documents, resources that may be best administered by XACML policies also have a tree like, hierarchical structure. This is e.g. the case with file systems. It is rather intricate to express access control demands for resources structured otherwise. When protecting business objects that are connected via associations with other business objects, this network model is rather awkwardly expressed in a hierarchical model most suitable for XML-oriented languages. Another example is the Java Security Architecture (JSA) [3]. JSA supplies the programmer with interfaces and classes for programming permissions and enforcing access control policies. The emphasis here lies on code access security, i.e. users may classify code into being trusted or not trusted by means of the code base, signatures of class files and the like. New to JSA is that security policies may also express access control decisions based on the principal that is running the code. Some predefined permissions accessing system resources like sockets, the file system, etc. are already being enforced by the security manager installed in the Java Runtime Environment. Enforcement of user-defined permissions has to be coded by hand. Therefore usage of JSA does not alleviate work when defining and implementing access control restrictions for arbitrary business objects. SecureUML [4] is a model driven approach to generating source code from a UML-model using special extension syntax to express role-based security demands. The role-based access control model used by SecureUML is a fixed model. For using different access control models, like DAC, a different extension syntax has to be developed. 3. The meta data model The meta model used throughout this paper (see Figure ) is similar to the object-oriented data model of the Meta Object Facility specification [5]. The objectoriented data model describes resources, namely the business objects as classes with properties and associations between them. Associations may have properties describing further qualities of the association. Common association kinds are one-tomany associations with cardinalities on the one-side and on the many-side and many-to-many associations with a cardinality of on both sides. Instances of associations that connect instances of classes are called links in this data model. Relational ER-diagrams as well as UML-class diagrams may be directly mapped to their meta model.

3 .. Role 2.. multiplicity Class Instance Weblog parent WEBLOGENTRY _WEBLOG WeblogEntry -text: String -view: int Property type.. Figure : Meta data model xor 4. Example data model author 0.. Group WEBLOG_AUTHOR reader 0.. WEBLOG_READER GROUP_MEMBER member Person owner -name:string WEBLOG_OWNER -isanonymous: boolean WEBLOGENTRY_AUTHOR entryauthor Figure 2: Example data model Association Link The following example application is used throughout this paper. The example (see figure 2) represents community software that manages weblogs. Weblogs are websites that are published by a Person and are updated frequently, e.g. daily. They consist of a list of WeblogEntries that are sorted in reversed chronological order. In the example below each weblog belongs to a designated person, the owner. Each weblog may be read by a Group of persons, the reader group, and entries may be written by an author group. The person creating an entry has special rights connected to this entry, so that the entry author association becomes necessary. Weblog entries may be either public (visible to a reader group) or private (visible to the entry author only). The entities Weblog, WeblogEntry, Person, and Group represent Instances from the meta data model. Instances and their properties are the resources that are to be protected by an access control system. They are stored in persistent storage and retrieved from storage and written on demand. Weblog_Author, Weblog_Reader, Weblog_Owner, WeblogEntry_Author are instances of one-to-many associations; Group_Member is an instance of a manyto-many association. As can be seen from this example, associations serve two purposes. They may express real associations, e.g. WeblogEntry_Weblog expresses a whole-part relationship between weblogs and its entries. Other associations are used to express access control features. Discretionary access control is based on ownership relations. WeblogEntry_Author and Weblog_Owner are two associations that express just this kind of access control relationship. For role-based access control, access rights are given to groups. In this example Weblog_Author and Weblog_Reader together with Group_Member form the associations expressing the role-based part of access control demands in the weblog application. 5. The service model When constructing access control models one has to choose an appropriate level and granularity for protecting resources. It is common practice to realize business applications with a three-tiered architecture. The first tier, the presentation layer, constitutes the front-end. This could e.g. be a web front-end. Business logic is encapsulated in the second tier, whereas the database makes up the third tier. In general, the business logic is structured rather simple. The main task of the business applications consists in processing client requests that essentially do nothing else than retrieving data from persistent storage, display this data for the client and writing back some updated data back to persistent storage. Interactions of clients with the system take place via predefined interfaces that are offered in the presentation layer. Of course, if the application does not have a visual front end, offered services are interfaces that have to be invoked by some other protocol. An example for this kind of service oriented applications is web-services. Operations protected by an access control system may be at different levels of granularity. One extreme may be to protect low-level operations like reading or writing properties of business objects, creating, deleting, reading, or writing associations. Alternatively, access control decisions may be enforced at a medium level, e.g. at the level of methods of business objects. This level offers more contexts of the semantics of protected operations but protected operations have to be mapped to low-level operations

4 of protected resources. The third possibility may be to protect high-level operations, i.e. processing of a complete client request. This procedure offers the most execution context but is also hardest to realize in a complete fashion, since access control enforcement takes place far away from the resources to be protected. Protecting low-level operations is not an appropriate level of abstraction for enforcing access control policies of business applications. Assume two different restriction policies, for creating and editing weblog entries in our example data model. Only members of the author group and the owner of a weblog are allowed to create a new entry. Once the entry is created, the contents may be only edited by the entry author, namely the person who created the entry. During execution of both actions, the properties (text and view in our example) are set. These set-operations map in both cases to the same low level writeoperation of properties. If access control is enforced at this low-level the context of whether these operations take place during creation or editing is lost. Therefore at this low level it cannot be decided whether these write operations should be allowed or denied. Access control could be enforced at the level of methods of business objects (medium level). But the same business method is called during processing several client requests. When changing one access control policy of one business object, it is not immediately clear which kinds of client requests are affected. An appropriate higher-level context is given by service methods. They correspond to the high-level access control context mentioned above. Before giving an example, the service model used in this paper is introduced (see Figure 3). It has a rather simple structure. A service consists of service methods. Clients issue service requests to execute some service method on a specific target. A client is a principal belonging to a session in which the service request is executed. The target is some concrete Instance of a business object. Also the initiator is represented by some Instance for example of Class Person in Figure 2. To execute a service method, some access restrictions must be fulfilled. These restrictions are formalized by path expressions described later in this paper. From the path expression one of two database queries may be built and executed in order to check whether execution of the service method should be allowed. Service ServiceMethod 0.. ServiceRequest authorized_subjects target Session Instance principal Figure 3: Service model PathExpression Every request issued by a client comprises one service method. In our weblog example possible service requests refer to coarse-grained actions of business objects. Service methods for weblog entries might be WeblogEntryCreate for creating a new weblog entry, WeblogEntryRemove for deleting an entry, WeblogEntryEditText for editing the contents of an entry, WeblogEntryMove to move the entry from one weblog to another, WeblogEntrySwitchView to switch from private to public visibility or vice versa. 6. The authorization model As explained above, access restrictions for business applications should be linked to service methods. A security policy should define for every service method a corresponding access restriction. Since the data model of business applications already contains relationships, i.e. associations, useful to describe rolebased and discretionary requirements, the access control model introduced here is based on navigating these relationships in the business application s data model. If we want to check whether some action is allowed to be executed on some target object by some initiating principal, we try to find a path between the target object and the object representing the principal along associations that express the security policy in effect. In other words, access is granted, if starting from the resource accessed navigation along one or more predefined path via associations and properties finally ending at the class representing the calling subject, that is the principal from the service model, is possible.

5 A PathExpression defines a declarative mapping from a given target object to a set of subjects. A ServiceRequest with a given subject s, a target t and a ServiceMethod with a PathExpression authorized_subjects is permitted, if the subject is an element of the set defined by the PathExpression. Class s ServiceMethod. authorized _ subjects( t) Access restrictions may be independent of the target. For example, some access restrictions may express that access is allowed for members of the administrator group independent from the target being accessed. In this case the authorized_subjects does not depend on the parameter t. The access control model consists of the following parts (see figure 4): domain PathExpression range Filter Edge operation value Role (from meta model) Property (from meta model) Class (from meta model) head Concat tail Figure 4: Path model left right Composition Or And Not Edge: An edge is a navigation from one class via an association denoted by a role name to another class. Roles in object orientation are names of association ends (rather than roles in the RBAC sense). Starting from a concrete domain object, navigation to another object is represented by the role name at the association end of the class denoting the range. In case the role name is missing, the name of the associated class can be used instead. If the association end has cardinality, then the result of the navigation will be a single object. If the association end is denoted 0 then the result may be empty. If the association end is, or otherwise denoted greater than one, then the result of the navigation will be a collection of zero, one or more objects. After a single navigation step the resulting collection represents a set since navigation targets are all distinct. Further navigation from a set of objects via a second edge either results in a collection of objects or a collection of sets of objects depending path on whether navigation starts from a single object or a set of objects respectively. Collections of sets are implicitly flattened to single sets with duplicates being removed. Filter: A filter is a path expression where domain and range objects are of the same type. By means of filters the collection resulting from path navigation may be constrained to a subset by restricting the range of values of a property of the object. Filter operators may be e.g. equals, smaller than, greater than, smaller or equal, greater or equal. If the filter is applied to a single domain object, the outcome may either be the one-element set containing the same object or the empty set. If the filter is applied to a set of domain objects, the filter operator will be applied to every element of the set. filter( property, operation, value) { x property. class operation( x, value) = true} Concat: A concatenation connects two paths, the head path with the tail path, to form a single longer path. The type of the range class of the head path must be equal to the type of the domain class of the tail path. head, tail) U tail( y) y head( x) Composition: Two paths with the same target class in the data model may be connected by and or or, meaning that the result contains subjects identified by both paths or at least one path respectively. union( left, right) { y y left( x) y right( x)} intersection( left, right) { y y left( x) y right( x)} Not: Not takes a PathExpression p from a class domain to a class range and yields the set of range objects in the class range that are not member of the set identified by p(domain). not( p) { y p. range y p( x)} 7. Example path expressions

6 To give an example how to apply the above path expressions, access restrictions on the two actions for creating and reading objects of the WeblogEntry-class are given below. The access restriction for calling the service method WeblogEntryCreate to create a new weblog entry is e.g. given by the following constraint given in clear text: Creating a new weblog entry is allowed, if the principal issuing the request is either the owner of the weblog or member of the author group of the weblog the weblog entry is created in. Weblog parent WEBLOGENTRY _WEBLOG WeblogEntry -text: String -view: int author 0.. Group WEBLOG_AUTHOR reader 0.. WEBLOG_READER GROUP_MEMBER member Person owner -name:string WEBLOG_OWNER -isanonymous: boolean WEBLOGENTRY_AUTHOR entryauthor Figure 5: Visualization of path expression for access restriction WeblogEntryCreate Figure 5 visualizes the path expression that must be fulfilled for this access restriction. The Weblog- EntryCreate restriction is a union set consisting of a discretionary and a role-based path. The discretionary path is a concatenation path of two edges (lower path in figure 5): ownerpath = edge(parent), edge(owner)) The role-based path concerning membership of the author group (upper path in figure 5) is a concatenation of three edges: authorpath= edge(parent), edge(author)), edge(member)) The result set of the path navigation is the union of all person objects that are authors with the person object representing the owner. weblogcreatepath = or(ownerpath, authorpath) Since the ownerpath and the authorpath both have a common sub-path, the overall path may also be constructed by using a concatenation of an edge with a union: weblogentrycreatepath = edge(parent), or( edge(author), edge(member)), edge(owner))) Executing the WeblogEntryCreate action is allowed, if the result set includes the caller who is also represented by an object of type person. The usage of filters may be shown by looking at the access restrictions for reading the contents of a weblog entry. The access restriction is as follows: The contents of a weblog entry with private visibility may be read by the entry author only. The contents of a weblog entry with public visibility may be read by all members of the reader group of the weblog the weblog entry belongs to. This access restriction constitutes an if-condition: If the weblog entry is private then the author may read it, otherwise members of the reader group may read it. This if-construct may be described by a union construct. Because a weblog entry may be either private or public, at most one of the two sub paths will yield a result that is not empty. privatepath = filter(view, =, PRIVATE), edge(entryauthor)) publicpath:= concat ( not(filter(view, =, PRIVATE)), edge(parent), edge(reader)), edge(member))) weblogentryreadpath = or(privatepath,publicpath)

7 8. Conclusion This paper shows how to use a simple path expression language to express role-based and discretionary access control in a single, easy to understand format. Since the access control model is based on the object-oriented data model, which by now can be considered a standard for building business applications, it can be applied to a wide range of applications. The service model is kept very simple so that monolithic business applications as well as web services are covered by the presented access control model. Besides subject-oriented access control policies like role-based and discretionary access control, there exist access constraints that are independent of the requesting subject. Examples are workflows, where access of a resource solely depends on the state of the resource. At the moment these cases cannot be covered by path expressions. Future work will include path expressions in reverse order, ending at the target, in order to also cover these resource-oriented access control demands. An advantage of the introduced path expressions is that they have a simple grammar. It is easy to express paths by OCL [6] (not shown in this paper) and annotate the data model with according OCL expressions to make access control policies transparent. Path expressions have a compact notation. Therefore it is possible to use them for mathematical analysis. Also path expressions may be used to automatically construct queries that may be uniformly translated to a database queries. Also access restrictions may be read directly from the data model. Future work will engage in using path expressions in an introspective framework. Then access control restrictions may be read directly from the source code. Also the object-oriented data model allows for some interesting visualization possibilities for showing access control restrictions directly on the data model. 9. References [] Ferraiolo, D. and Sandhu, R. and Gavrila, S. and Kuhn, R. and Chandramouli, R., Proposed NIST Standard for Role-Based Access Control, ACM Transaction on Information and System Security, Vol. 4 (200), No. 3, pp [2] Godik, S. and Moses, T. et al. extensible Access Control Markup Language (XACML), February 2003 [3] Java Security Architecture, API-Specification, (visited February 2005) [4] Lodderstedt, T. and Basin, D. and Doser, J., SecureUML: A UML-Based Modeling Language for Model-Driven Security, In: Jézéquel, J.-M., and Hussmann, H. and Cook, S.: UML 2002 The Unified Modeling Language. Model Engineering, Languages, Concepts, and Tool. 5 th International Conference, Dresden, Germany, September/October Proceedings Vol. 2460, Springer- Verlag, 2002, p [5] OMG, Meta Object Facility (MOF) Specification, April 2002 [6] OMG, UML 2.0 OCL Specification, November 2003