Context-Dependent Access Control for Web-Based Collaboration Environments with Role-Based Approach

Transcription

1 Context-Dependent Access Control for Web-Based Collaboration Environments with Role-Based Approach Ruben Wolf and Markus Schneider Fraunhofer Gesellschaft (FhG), Institute for Secure Telecooperation (SIT) Darmstadt, Germany Abstract. Controlling access to resources is one of the most important protection goals for web-based collaboration environments in practice. In general, access control requires identification of subjects that intend to use resources. Today, there are several identification mechanisms for subjects, providing different security levels. However, some of them are only suitable to be used in specific environments. In this paper we consider access control to web-based collaboration environments where access control also depends on the actually used identification mechanism as a context-dependent parameter. Furthermore, we show how to model this kind of context-dependent access control for web-based collaboration environments by using role-based concepts. Additionally, we present how complex role hierarchies in the context-dependent case can be generated from basic role hierarchies. This is achieved by applying direct products as a special arithmetic operation over role hierarchies and context hierarchies. 1 Introduction The World Wide Web provides powerful means for nowadays collaboration environments. Collaboration environments include a bunch of tools and resources to support team work. After former collaboration environments have mostly been applications with specific clients, the trend is towards providing collaboration environments with webbased user interfaces for accessing the offered services with a simple web browser. For an overview about existing collaboration environments we refer to [1,2]. However, when dealing with collaboration services provided over open networks, security questions like controlling access to offered services are of central interest in collaboration environments. Access control is usually strongly related to identification of the requesting user. There are several technical solutions which are used in practice, e.g., challenge & response protocols based on digital signatures and public key certificates (e.g., as in [3,4]), passwords (e.g., as in [5]), and even cookies [6]. The decision which of these identification mechanisms has to be applied depends on the protection goals in the corresponding application and the desired security level. High-level protection goals usually require stronger mechanisms. Thus, the usage of specific functions within the collaboration environment may only be allowed to be requested after identification with well-chosen mechanisms. In today s web practice, access to web-based collaboration environments requires always one specific mechanism. On the other hand, there V. Gorodetsky et al. (Eds.): MMM-ACNS 2003, LNCS 2776, pp , c Springer-Verlag Berlin Heidelberg 2003

2 268 R. Wolf and M. Schneider are situations where different identification mechanisms can be reasonable in order to access collaboration environments from different locations, e.g., identification via an asymmetric key pair / certificate from the user s own computer and identification via passwords from a public computer. Of course, the user s permissions should also depend on the strength of identification. Thus, in the case of multiple supported identification mechanisms, the mechanism applied can be an important parameter to be respected as a context in the access control decision. In the following, when we use the term certificate we always assume X.509 certificates due to their wide deployment. In general, there are several paradigms for the realization of access control. The idea of role-based access control (RBAC) has been extensively discussed in the past years and is considered to be highly attractive, e.g., see [7,8]. Recently, RBAC was proposed for access control in the web environment [9,10]. In this work, we propose the consideration of multiple identification mechanisms for controlling access in web-based collaboration environments. We demonstrate the realization of access control in collaboration environments using RBAC concepts. We present a new and efficient approach for generation of complex and context-dependent role hierarchies. Here, the context-dependent role hierarchies are produced by applying special arithmetic operations over partially ordered sets, i.e., the direct product, to the role hierarchy and a hierarchy which is built over identification mechanisms. Furthermore, we show how roles are activated in web-based collaboration scenarios. 2 Collaboration Environments and UNITE Work environments have changed. There is a upward trend to team work, mobile workers traveling among different companies premises, and non-territorial work environments. Mobile workers need to access documents and resources, for example. Modern webbased collaboration environments allow users to access all required resources from a web-based user interface [2,1]. Today s collaboration environments usually provide an integrated user interface to all kind of features that support teams during their work. These may comprise address book, calendar, , document repository, fax, messaging, video conferencing, voice-over-ip, text chat, whiteboard, application sharing, and support for team awareness. In the EU-IST project UNITE (Ubiquitous and Integrated Teamwork Environment) 1 Fraunhofer SIT has developed an advanced web-based collaborative team work environment together with international partners. The objective of the UNITE project is to support globally dispersed team work in information technology, by providing a collaboration platform with virtual project offices where members of project teams can meet to exchange documents or launch collaboration and communication tools, regardless where they are physically located by utilizing a Java-enabled web browser [11]. In UNITE, users are dynamically assigned to teams, whereas teams represent the different work contexts. Each user can work in just one work context at the same time; this is exactly the way as one usually works in the real world. Users can switch the work context by leaving the actual team and entering a new team. All tools, services and resources are 1 The UNITE project is funded by the EU under the Information Society Technologies (IST) Programme, Project-No. IST Project Homepage:

3 Context-Dependent Access Control for Web-Based Collaboration Environments 269 Collaboration Environment User uses assigned to Team Role Identification Mechanism influences influences requests Constraint allows / refuses Access Control Operation on Object Fig. 1. Context-dependent access control configured on a team basis. Thus, there may be different services available in different teams. In the same way, security policies are configured on a work context basis, i.e., teams may different security policies. The features provided by today s collaboration environments can be considered to be basic services which may comprise one or more operations on objects on the web server side. The users requests to apply these operations on objects have to be checked against the underlying security policy. Of course, if operations are not allowed for all users, such a check requires that the identity of the requesting user has been verified through a well-chosen identification mechanism, adequate for the values to be protected. The support of different identification mechanisms and the consideration of the chosen mechanism in the access control decision may be relevant in collaboration environments, as it will be explained below. Here, the goal is to consider the specific mechanism which is used for identification as a context parameter for access control decisions. Context-dependent access control can be motivated as follows. Consider a mobile worker with the intend to access his collaboration environment from his own computer but also from a public computer somewhere in the world. Assume that from his computer at his office this user identifies himself to the collaboration environment through the possession of his private key and his certificate. For sensitive operations, high security level provided by an asymmetric key pair / certificate identification is necessary. Assume now, that the same user wants to use the collaboration environment while he is traveling and only having access from an Internet cafe or from a machine in a partner company by using a web browser. Such a user would not want, or is not allowed, to expose his private key to a potential untrusted environment. In this case, password identification might be desirable for less critical operations. However, for security reasons, more critical operations should be refused when the user identifies himself using a password. In the context of collaboration environments, critical operations are, e.g., the deletion of a project s workspace, and the modification of account data, while a less critical task is a lookup in the project s address book. Within a collaboration environment one can consider various roles. First, there are different projects; some users may have access to project T1 and project T2 while others may only have access to project T2. Second, there are different roles within a project. For example, besides a default project member role, there may be a role project initiator, which is assigned to the user that creates and deletes the project and invites new team members, or there may be a project operator role, which is assigned to users that are responsible for configuring the project resources. Suppose now a security policy where a project initiator may invite new team members when he identified with either password or asymmetric key pair / certificate. But for deleting the project, he needs to identify

4 270 R. Wolf and M. Schneider users UA roles PA operations permissions objects Fig. 2. UA and PA using an asymmetric key pair / certificate. In this scenario, a possible attacker obtaining the team initiator user name and password may only invite new members, but is not able to destroy existing projects. The considerations above show that there are good reasons to differentiate different kinds of access to resources depending on the level of identification. Figure 1 summarizes the aspects mentioned above in a domain model as it is used in software engineering. 3 Role-Based Access Control In this section, the main ideas in RBAC are presented. Since the general concepts of RBAC are well-understood and extensively described in the literature [8,12], we will only briefly describe the key aspects. Basic Idea. The central terms in RBAC are user, role, and permission. Therefore, we have sets USERS, ROLES, and PERMS. For elements of these sets, we have two assignment relations UA USERS ROLES and PA PERMS ROLES. The user assignment UA defines a relation between users and roles, whereas the permission assignment PA defines the relation between roles and permissions. Both relations are many-to-many. The set of all permissions is obtained by the combination of operations and objects, i.e., PERMS = OPS OBS, where OPS and OBS are the corresponding sets. Types of operations depend on the type of system which is considered. In access control terminology, an object is an entity which contains or receives information, e.g., an object may be a file or some exhaustible system resources. If a user u USERS changes to a new user category leaving his old role r old then he is simply assigned to a new role r new by getting the permissions of r new and losing the permissions of r old. RBAC facilitates security management, makes it more efficient, and reduces costs. Role Hierarchy. Role hierarchies are thought to be one of the most desirable features in RBAC. They are very useful when overlapping capabilities of different roles result in common permissions because they allow to avoid repeated permission-role assignments. This allows to gain efficiency, e.g., when a large number of users is authorized for some general permissions. Role hierarchies RH ROLES ROLES are constructed via inheritance relations between roles, i.e., by the introduction of senior and junior relations between roles r 1 r 2 in such a way that the senior role r 1 inherits permissions of the junior role r 2. To put it more formally, if we have roles r 1 and r 2 with r 1 r 2, then (auth perms(r 2 ) auth perms(r 1 )) (auth usrs(r 1 ) auth usrs(r 2 )). These mappings are defined as auth perms:roles 2 PERMS,auth perms(r) ={p PERMS r r, (p, r ) PA}, auth usrs : ROLES 2 USERS, auth usrs(r) ={u USERS r r, (u, r ) UA}.

5 Context-Dependent Access Control for Web-Based Collaboration Environments 271 The opposite is not true, i.e., if (auth perms(r 2 ) auth perms(r 1 )) (auth usrs(r 1 ) auth usrs(r 2 )) is fulfilled, then it is still up to the role engineer to decide whether to introduce an inheritance relation between r 1 and r 2 or not. Multiple inheritance means that a role inherits both permissions and role memberships from two or more roles. With the concept of multiple inheritance, these hierarchies provide a powerful means for role engineering, i.e., it is possible to construct roles from many junior roles. Role hierarchies are modeled as partial orders. Fig. 4.1 in the next section depicts a sample role hierarchy. Role Activation and Sessions. In a role hierarchy, a senior role inherits the permissions from the junior role. But a user does not necessarily have to act in the most senior role(s) he is authorized for. Actual permissions for a user are not immediately given by evaluating the permission assignment of his most senior role(s); these roles can remain dormant. Instead, actual permissions depend on the roles which are activated. A user may decide which roles to activate. Sessions are defined over phases in which users keep roles activated. A user s session is associated with one or many roles. Principle of Least Privilege. The principle of least privilege requires that a user should not obtain more permissions than actually necessary to perform his task, i.e., the user may have different permissions at different times depending on the roles which are actually activated. As a consequence, permissions are revoked at the end of sessions. Static Separation of Duty. In some security policies, there may arise a conflict of interest when users get some user-role assignments simultaneously. The idea of static separation of duties is to enforce some constraints in order to prevent mutually exclusive roles. In the presence of a role hierarchy, inheritance relations have to be respected in order to avoid infringing these constraints. Dynamic Separation of Duty. The goal of dynamic separation of duty is similar to static separation of duty to limit permissions for users by constraints in order to avoid potential conflicts. The difference here is that these constraints define which roles are not allowed to be activated simultaneously, i.e., the constraints focus on activation of roles. Roles obeying these constraints can be activated when they are required independently, but simultaneous activation is refused. Further Relevant Properties. RBAC is assumed to be policy-neutral. This means that RBAC provides a flexible means to deal with arbitrary security policies. It is highly desirable to have a common means to express a huge range of security policies. In classical role-based access control work, roles are assumed to be related to jobs or functions of persons in enterprises or institutions with some associated semantics which express authority and responsibility. In the following, we will show how RBAC can be used in order to solve access control problems for collaboration environments where permissions are dependent on the underlying identification mechanism as a contextdependent parameter of interest. 4 Role Hierarchy and Context Hierarchy The reason for introducing roles was to efficiently assign users to specific sets of permissions. If a member of a role tries to initiate an operation on an object, where this role is not

6 272 R. Wolf and M. Schneider TI 1 TO 1 TM 1 TI 2 TO 2 TM 2 Cert B Pw Fig. 3. Hierarchies for (a) collaboration environment roles PO 1 and (b) sample contexts PO 2 authorized for the corresponding operation on a specific object, the requested operation is refused. Before modeling context-dependent access control for collaboration environments using the RBAC approach, we introduce a role hierarchy for a typical collaboration environment that will be used throughout the whole paper. For this, Sect. 4.1 introduces a sample role hierarchy for a collaboration environment. After that, we give a second hierarchy representing the security levels of identification mechanisms in Sect Here, we consider the supported identification mechanisms as a context parameter. This is just an example for a context, one may think of others, e.g., used communication protocol (http or https). For this hierarchy, we use the term context hierarchy. 4.1 Hierarchy for Collaboration Environments Collaboration environments usually offer different types of user permissions. In Sect. 2, we have already given an overview of possible roles that users can be assigned to. Here, we will provide a role hierarchy containing all the roles of our sample scenario. Additionally, we will outline sample permissions of these roles. Our scenario consists of two different projects. There are three roles within a project: team member, team initiator and team operator. Additionally we have a base role which is relevant for users that are currently not active in any project. Role TM 1 (Team Member of Project T1): This role is for normal project member in project T1. The users assigned to this role may access resources for regular team work. Role TI 1 (Team Initiator of Project T1): This role is assigned to the initiator of project T1. The project initiator is allowed to invite new team members to the project. He is also allowed to change the project description and to delete the project. Role TO 1 (Team Operator of Project T1): This role is assigned to users that are responsible for administrative tasks within a project. The team operator may select the tools and resources that may be used in project T1. Roles TM 2 (Team Member of Project T2), TI 2 (Team Initiator of Project T2) and TO 2 (Team Operator of Project T2) are analogously defined as in project T1. Role B (Base Role): This role contains all minimal permissions assigned to all users of the collaboration environment. It is also assigned to users that are currently not active in specific projects. Figure 4.1 depicts the partial order of the roles introduced above. Role B is the most junior role. The left subtree shows all roles of project T1 the right subtree contains all roles of project T2. Within a project there are two most senior roles, the Team Initiator and the Team Operator.

7 Context-Dependent Access Control for Web-Based Collaboration Environments 273 = P Q P Q Fig. 4. Direct product P Q 4.2 Context Hierarchy In Sect. 2, we have mentioned that different identification mechanisms provide different levels of protection. Thus, access control systems, which use identification results for their access control decisions, should take this level of protection into consideration. Consequently, in context-dependent access control systems, where the relevant context parameter is defined by the identification mechanism, there should be different levels of permissions which depend on the context parameter. In classical RBAC, different levels of permissions are aggregated to roles. If the usage of different identification mechanisms implies different permissions, then these mechanisms should influence the composition of the corresponding roles in role engineering. This means that the identification mechanisms such as certificates in combination with a challenge & response protocol, passwords, or cookies will be considered in the definition of roles. We illustrate this idea by means of a sample hierarchy for protection levels, i.e., the context hierarchy. Suppose a collaboration environment supporting two kinds of identification mechanisms: identification by user name / password, and by an asymmetric key pair / certificate. This is depicted in Fig If a user A is authorized to access a collaboration environment by identifying with a certificate in a challenge & response protocol, then user A will be assigned to a context Cert PO 2. The context Cert is authorized for a specific permission set PS cert PERMS. Another user B which decided to identify himself with a password should be authorized to a context PW PO 2. Analogously, he is authorized for permission set PS Pw PERMS. If both users identify themselves with their chosen identification mechanisms, they are automatically authorized for the permissions which are assigned to their corresponding roles. With the introduction of roles, administration tasks become more efficient. A whole set of users can obtain new permissions by just assigning new permissions to their specific role. For changes in the access policy for contexts like Cert or PW, this adaption can be done easily. In practice, the role hierarchy and the context hierarchy can be more complex than shown in the example. In real-world collaboration environment examples, there may be more roles necessary in order to express the relevant access control categories for permission assignment. In this context, there may be further roles for the categorization of tasks within a project or the support of sub-groups of members within projects, e.g., roles for different work packages with corresponding permissions. However, the roles given in the example above might be sufficient in order to get the idea on how to deal with the problem of different security levels of identification mechanisms in access control, and how to construct more complex role hierarchies. 5 Arithmetic over Partially Ordered Sets The properties of partially ordered sets required for our purposes will be outlined in this section. Since the theory of partially ordered sets is well-understood and described in

8 274 R. Wolf and M. Schneider detail in the literature, we only describe the aspects that are required to model contextdependent access control. For more information, we refer to [13,14]. Definition 1 (Partially Ordered Set P ; [13]). Let P be a set. A partial order on P is a binary relation on P such that for all x, y, z P there holds (i) x x (reflexivity), (ii) x y and y x imply x = y (antisymmetry), and (iii) x y and y z imply x z (transitivity). Without introducing contexts, we can specify role hierarchies for role-based access control with the definition above. We suggest now to model the context itself as a partially ordered set and then compose a new hierarchy, i.e., the context-dependent role hierarchy, by applying a specific arithmetic over partially ordered sets. With the help of the direct product (which is sometimes also called Cartesian product), we create the contextdependent role hierarchy from the role hierarchy and the context hierarchy as specified in Sect. 4. Definition 2 (Cartesian Product P 1 P n of Partially Ordered Sets [13]). Let P 1,...,P n be ordered sets. The Cartesian product P 1 P n can be made into an ordered set by imposing the coordinate-wise order defined by (x 1,..., x n ) (y 1,..., y n ) ( i) x i y i in P i. Informally, a product P Q is drawn by replacing each point of a diagram of P by a copy of a diagram of Q, and connecting corresponding points. Figure 4 depicts a direct product P Q of two partially ordered sets P and Q. 6 Role Hierarchy for Context-Dependent Access Control In this section, we combine the arguments given in Sects. 2 to 5, and thereby, we establish a connected motivation for what follows. In Sect. 2, it was motivated that access control decisions should also take the identification mechanism into account as a relevant context parameter. This idea combines an adequate protection level with reasonable user requirements and convenience aspects. Since a collaboration environment may support a large number of users, where the assignment from users to projects may change dynamically, such collaboration environments pose demanding requirements to security administration systems. Furthermore, providers of collaboration environments have an interest, that changes in the security policy can be dealt with easily and efficiently, e.g., by the introduction of new permissions, or new team roles. This means that they require adequate support for administration. RBAC, as presented in Sect. 3, dramatically simplifies access control management, which is extremely valuable for large number of users or permissions. It also supports the requirement for flexibility in presence of frequently changing access control policies. Consequently, there arises the question how RBAC can be used to provide efficient solutions for controlling context-dependent access to web-based collaboration environments exploiting the advantages of RBAC. Thus, our goal is to provide answers on how to approach and model collaboration environment requirements for context dependency with RBAC.

9 Context-Dependent Access Control for Web-Based Collaboration Environments 275 TICert 1 TOCert 1 TICert 2 TOCert 2 TIPw 2 TMCert TMCert 1 TOPw 2 TIPw 1 TOPw 2 1 TMPw 1 BPw BCert TMPw 2 Fig. 5. Context-dependent Role Hierarchy PO 3 = PO 1 PO 2 In Sect. 4, we provided two sample hierarchies for collaboration environment roles and contexts. For context-dependent access control, we will create a new role hierarchy by utilizing the direct product of partial orders. For that, we assume the two hierarchies to be independent from each other, i.e., there are no inferences between roles and contexts. The resulting role hierarchy integrates the context parameter into the collaboration environment role hierarchy. Therefore, it provides context-dependent access control for collaboration environments, where the context, i.e., the identification mechanism selected by the user, is used as a parameter for the access control decision. Since both hierarchies are partially ordered sets, the result is a partially ordered set again, and thus, can be interpreted as a role hierarchy. Figure 5 presents this new role hierarchy. It includes all new introduced roles, which are the result of the direct product of PO 1 and PO 2, and depicts the inheritance relations among these roles. We will explain some of the roles in order to give an impression of the meaning of particular roles. For example, role TMPw 1 is for all team members of project T1 which identify themselves with password. In contrast, role TMCert 1 is for team members of project T1 which identify themselves with certificates. TMPw 1 should provide less permissions, since the protection level is lower than for TMCert 1. We may, for example, think of the following permissions. Role TMPw 1 has the permission to initiate all communication tools except, for billing reasons, PSTN telephony, while role TMCert 1 has the permission to make PSTN telephone calls (and inherits all the permissions of TMPw 1, of course). Additionally, the new role hierarchy includes a role TIPw i, i =1, 2, which has the permission to invite new team members, but forbids dropping the project workspace, and a role TICert i which also allows deleting the project workspace. Table 1 gives a summary of all roles. The table shows the particular role according to the project, the user s role within the project and the chosen identification level. 7 Discussion The approach above uses the actually chosen identification mechanism as a context parameter. However, this is only an example; one may think of many other contexts. In addition, our approach can be generalized to consider more than one context simultaneously by applying the direct product to the basic role hierarchy and several context hierarchies. 7.1 Automated Role Activation After having generated the complex role hierarchy, we explain how roles can be activated. In general, if a user is assigned to several roles, it is up to him to decide which role(s)

10 276 R. Wolf and M. Schneider Table 1. Roles for context-dependent access control Collaboration Protection Level Environment Role Password Certificate Project T1 Member TMPw 1 TMCert 1 Initiator TIPw 1 TICert 1 Operator TOPw 1 TOCert 1 Project T2 Member TMPw 2 TMCert 2 Initiator TIPw 2 TICert 2 Operator TOPw 2 TOCert 2 Base Role BPw BCert no rs = start check identity registered? yes rs = allowedr(juniorr( assignedr(u))) activate roles in rs stop Fig. 6. Role activation he is authorized to activate. In our work, the user does not select the role to be activated directly. Web-based user interfaces differs from other environments, such as operating systems or databases, in that they follow a simple request-response schema, i.e., the client sends a request and the server returns the corresponding response. Instead, the role activation in our approach depends on the way the user identifies himself. Thus, one can say that a user selects the role to be activated indirectly. This means that dependent on identification aspects, the user role to be activated is selected by the access control system. In order to describe how and which roles are activated we introduce some mappings. For formalization reasons, we define IDMS as the set containing the identifiers of identification mechanisms supported by the corresponding collaboration environment. assignedr : USERS 2 ROLES, assignedr(u) ={r ROLES (u, r) UA}. The result of assignedr(u) is the set of roles for which user u is assigned according to UA. juniorr :2 ROLES 2 ROLES, juniorr(rs) ={r ROLES r r,r rs}. The result of juniorr(rs) is the set consisting of all roles which are in a junior inheritance relation to the roles contained in the set rs. allowedr : IDMS 2 ROLES 2 ROLES, allowedr(im, rs) ={subset of rs authorized for im}. Given an identification mechanism im and a set of roles rs, the relation allowedr(im, rs) filters all roles which are allowed for activation. When the collaboration environment receives a request, roles will be activated dependent on whether the user identifies, how he identifies, and whether he is a registered user. The procedure according to which roles are selected for activation is depicted in Fig. 6. With the activation of one role, all roles in junior inheritance relations are activated. In this way, the requesting user also obtains the permissions of all junior roles. Roles to be activated are selected automatically according to the mechanism shown in Fig Constrained RBAC for Collaboration Environments Constraints in RBAC deal with static and dynamic separation of duty. This means that the RBAC system either controls that no users are assigned to conflicting roles according

11 Context-Dependent Access Control for Web-Based Collaboration Environments 277 to the underlying security policy (static separation of duties), or users cannot be activated for conflicting roles simultaneously (dynamic separation of duty). The example we have introduced in figure 5 does not make use of separation of duty aspects. However, in a concrete collaboration environment, there may be other constraints which follow from potential conflicts resulting from the underlying security policy. E.g., consider a model in which a user can only be active in a single project per session. This means that, he explicitly needs to log in to and log out from a particular project. While working in that project, each request to a resource needs to be checked, whether it is a resource of the current project; if not, then the user has to be informed that he needs to exit the current project, first. This scenario could be modeled using constraints. 8 Related Work In the past years, there have been various contributions to the area of RBAC which emerged as an alternative of classical discretionary and mandatory access control approaches. Ongoing research activities in RBAC resulted in the first proposed NIST standard for RBAC [8]. In the past, RBAC was mainly used for database management and network operating systems. Up to now, there are only a few contributions considering the usage of RBAC in the web context, even if RBAC is assumed to be a promising alternative for this area [10]. But in practice, protection on the web is still dominated by traditional concepts [9], e.g., access control lists. The first proposals for the usage of RBAC for the WWW is given in [15,16,17]. In the PERMIS project a role-based access control infrastructure was developed that uses X.509 certificates [18]. In this work, user roles and the permissions granted to the roles are contained in X.509 attribute certificates. In contrast to this approach, we do not store roles and permissions in attribute certificates since certificates have to be renewed after some period, and they can become invalid before their expiration date, which requires the introduction of revocation mechanisms. The Generalized Role-Based Access Control approach [19] models contexts in residential computing infrastructures using object roles and environment roles. Georgiadis et al. developed a model for team-based access control using contexts (C-TMAC) [20] by providing user contexts (e.g., the team membership) and object contexts (e.g., set of objects required for certain tasks). In these works, contexts are not integrated into the role hierarchy. Instead, they store them in a separate structure. The contexts are considered as an additional step in each access control decision. The second aspect of our work deals with the context-dependency respecting security level of identification for access control decisions of web-based collaboration environments which has not been considered so far. In our opinion, this idea is of high relevance for access control in web-based collaboration environments, where mobile users cannot always access the collaboration environment via their own computers. 9 Conclusion In this work, we have shown how to model access control for web-based collaboration environments with RBAC since RBAC provides promising properties for controlling

12 278 R. Wolf and M. Schneider access in web-based collaboration environments. We have motivated the need for considering context-dependent parameters such as the identification mechanism in the access control decision in web-based collaboration environments. Furthermore, we have modeled context-dependency with RBAC. We have shown how to model contexts as partially ordered sets and how complex context-dependent role hierarchies can be obtained in an efficient and systematic way. The combination of context-dependent aspects for webbased collaboration environments and their modeling in RBAC goes beyond what is done in today s web practice and allows new possibilities. References 1. Bafoutsou, G., Metzas, G.: Review and functional classification of collaborative systems. International Journal of Information Management (2002) Meier, C., Benz, H.: Business process requirements and paradigm of co-operative work: Enhanced Platform. UNITE Project Deliverable (2002) 3. Freier, A., Karlton, P., Kocher, P.: The SSL protocol version 3.0. Internet Draft (1996) 4. Dierks, C., Allen, C.: The TLS protocol version 1.0. RFC 2246 (1999) 5. Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., Berners-Lee, T.: Hypertext Transfer Protocol HTTP/1.1. RFC 2616 (1999) 6. Kristol, D., Montulli, L.: HTTP State Management Mechanism. RFC 2109 (1997) 7. Sandhu, R., Ferraiolo, D., Kuhn, R.: The NIST model for role-based access control: towards a unified standard. In: 5th ACM workshop on Role-based Access Control, (2000) 8. Ferraiolo, D., Sandhu, R., Gavrila, S., Kuhn, D., Chandramouli, R.: Proposed NIST standard for role-based access control. ACM Trans. on Inf. and Syst. Security 4 (2001) 9. Bertino, E., Pagani, E., Rossi, G., Samarati, P.: Protecting information on the web. Comm. of the ACM 43 (2000) 10. Joshi, J., Aref, W., Spafford, E.: Security models for web-based applications. Comm. of the ACM 44 (2001) 11. Zapf, M., Reinema, R., Wolf, R., Türpe, S.: UNITE an agent-oriented teamwork environment. In: 4th Intern. Workshop, MATA Number 2521 in LNCS, (2002) Sandhu, R.: Role activation hierarchies. In: 3rd ACM workshop on Role-based access control, (1998) 13. Davey, B., Priestley, H.: Introduction to Lattices and Order. Cambridge Univ Press (2002) 14. Jonsson, B.: Arithmetic of ordered sets. In Rival, J., ed.: Ordered Sets. Proceedings of the NATO Advanced Study Institute. (1981) 15. Barkley, J., Cincotta, A., Ferraiolo, D., Gavrilla, S., Kuhn, D.: Role-based access control for the world wide web. In: 20th National Information Systems Security Conference. (1997) 16. Park, J., Sandhu, R., Ahn, G.: Role-based access control on the web. ACM Trans. on Inf. and Syst. Security 4 (2001) 17. Tari, Z., Chan, S.: A role-based access control model for intranet security. IEEE Internet Computing 1 (1997) 18. Chadwick, D., Otenko, A.: The PERMIS X.509 role based privilege management infrastructure. In: 7th ACM Symposium on Access Control Models and Technologies, (2002) 19. Covington, M., Moyer, M., Ahamad, M.: Generalized role-based access control for securing future applications. In: 23rd Nat. Inform. Syst. Security Conference, Baltimore, MD (2000) 20. Georgiadis, C., Mavridis, I., Pangalos, G., Thomas, R.: Flexible team-based access control using contexts. In: 6thACM Symposium on Access Control Models and Technologies. (2001) 21 30