for Web-Based Collaboration Environments
with Role-Based Approach
Ruben Wolf and Markus Schneider
Fraunhofer Gesellschaft (FhG), Institute for Secure Telecooperation (SIT) Darmstadt, Germany
{ruben.wolf,markus.schneider}@sit.fraunhofer.de
Abstract. Controlling access to resources is one of the most important protection goals for web-based collaboration environments in practice. In general, access con-trol 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 environ-ments. 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 web-based 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 col-laboration 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 collabo-ration environments requires always one specific mechanism. On the other hand, there V. Gorodetsky et al. (Eds.): MMM-ACNS 2003, LNCS 2776, pp. 267–278, 2003.
c
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 termcertificate 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 web-based 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, e-mail, document repository, fax, messag-ing, video conferencmessag-ing, voice-over-IP, text chat, whiteboard, application sharmessag-ing, 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 envi-ronment together with international partners. The objective of the UNITE project is to support globally dispersed team work in information technology, by providing a col-laboration platform with virtual project offices where members of project teams can meet to exchange documents or launch collaboration and communication tools, regard-less 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-2000-25436. Project Homepage: http://www.unite-project.org.
Operation on Object
requests
-Collaboration Environment User
6Constraint allows / refuses ? uses ? assigned to Access Control -influences Team Role -influences Identification Mechanism
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 opera-tions 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, ade-quate 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 projectT1and projectT2while others may only have access to projectT2. 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
objects -operations permissions PA -roles UA -users Fig. 2.UAandPA
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 adomain modelas 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 areuser,role, andpermission. Therefore, we have setsUSERS,ROLES, andPERMS. For elements of these sets, we have two assignment relationsUA⊆USERS×ROLESandPA⊆PERMS×ROLES. Theuser assignment UAdefines a relation between users and roles, whereas thepermission 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 ofoperationsandobjects, i.e.,PERMS = OPS×OBS, whereOPS andOBS are the corresponding sets. Types of operations depend on the type of system which is considered. In access control ter-minology, 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 useru∈USERSchanges to a new user category leaving his old roleroldthen he is simply assigned to a new rolernew
by getting the permissions ofrnewand losing the permissions ofrold. RBAC facilitates
security management, makes it more efficient, and reduces costs. 2
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 hierarchiesRH ⊆ ROLES×ROLES are constructed via inheritance relations between roles, i.e., by the introduction of senior and junior relations between rolesr1r2in such a way that the senior roler1inherits permissions of the junior roler2. To put it more formally, if we have rolesr1andr2withr1r2, then(auth perms(r2) ⊆ auth perms(r1))∧(auth usrs(r1) ⊆ auth usrs(r2)). These mappings are defined as
•auth perms:ROLES→2PERMS,auth perms(r) ={p∈PERMS|rr,(p, r)∈PA},
The opposite is not true, i.e., if(auth perms(r2)⊆auth perms(r1))∧(auth usrs(r1)⊆ auth usrs(r2))is fulfilled, then it is still up to the role engineer to decide whether to introduce an inheritance relation betweenr1andr2or 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. 2
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. 2
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. 2
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. 2
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. 2
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. 2 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 context-dependent parameter of interest.
4
Role Hierarchy and Context Hierarchy
The reason for introducing roles was to efficiently assign users to specific sets of permis-sions. If a member of a role tries to initiate an operation on an object, where this role is not
TI1 TO1 TM1 TI2 TO2 TM2 B Pw Cert
Fig. 3.Hierarchies for (a) collaboration environment rolesP O1and (b) sample contextsP O2 authorized for the corresponding operation on a specific object, the requested operation is refused. Before modeling context-dependent access control for collaboration environ-ments 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 hi-erarchy representing the security levels of identification mechanisms in Sect. 4.2. 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 termcontext 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 initiatorandteam operator. Additionally we have abase rolewhich is relevant for users that are currently not active in any project.
•Role TM1(Team Member of ProjectT1): This role is for normal project member in projectT1. The users assigned to this role may access resources for regular team work.
•Role TI1 (Team Initiator of Project T1): This role is assigned to the initiator of projectT1. 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 TO1 (Team Operator of ProjectT1): This role is assigned to users that are re-sponsible for administrative tasks within a project. The team operator may select the tools and resources that may be used in projectT1.
•Roles TM2(Team Member of ProjectT2), TI2(Team Initiator of ProjectT2) and TO2 (Team Operator of ProjectT2) are analogously defined as in projectT1.
•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 projectT1the right subtree contains all roles of projectT2. Within a project there are two most senior roles, the Team Initiator and the Team Operator.
P
×
Q
=
P×Q
Fig. 4.Direct productP×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 iden-tification 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. 4.1. If a userAis 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 ∈ PO2. The context Cert is authorized for a specific permission setPScert ∈ PERMS. Another userBwhich decided to identify himself with a password should be authorized to a contextPW ∈ PO2. Analogously, he is authorized for permission setPSP w ∈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 likeCertorPW, 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
detail in the literature, we only describe the aspects that are required to model context-dependent access control. For more information, we refer to [13,14].
Definition 1 (Partially Ordered SetP;≤[13]).Let P be a set. A partial order onP is a binary relation≤onP such that for allx, y, z ∈ P there holds (i)x≤x (reflexivity), (ii)x≤yandy≤ximplyx=y(antisymmetry), and (iii)x≤yandy≤ zimplyx≤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 context-dependent role hierarchy from the role hierarchy and the context hierarchy as specified in Sect. 4.
Definition 2 (Cartesian ProductP1× · · · ×Pnof Partially Ordered Sets [13]).
LetP1, . . . , Pnbe ordered sets. The Cartesian productP1× · · · ×Pncan be made into an ordered set by imposing the coordinate-wise order defined by
(x1, . . . , xn)≤(y1, . . . , yn) ⇐⇒ (∀i)xi≤yiinPi.
Informally, a productP×Qis drawn by replacing each point of a diagram ofP by a copy of a diagram ofQ, and connectingcorrespondingpoints. Figure 4 depicts a direct productP×Qof two partially ordered setsP andQ.
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 con-text 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 dy-namically, 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 poli-cies. Consequently, there arises the question how RBAC can be used to provide efficient solutions for controlling context-dependent access to web-based collaboration environ-ments 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.
TIPw1 TOPw1 TMPw1 TICert1 TOCert1 TMCert1 TIPw2 TOPw2 TMPw2 TICert2 TOCert2 TMCert2 BPw BCert
Fig. 5.Context-dependent Role HierarchyP O3=P O1×P O2
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 con-texts. 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 se-lected 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 ofPO1andPO2, 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 TMPw1 is for all team members of projectT1 which identify themselves with password. In contrast, role TMCert1is for team mem-bers of projectT1which identify themselves with certificates. TMPw1should provide less permissions, since the protection level is lower than for TMCert1. We may, for ex-ample, think of the following permissions. Role TMPw1has the permission to initiate all communication tools except, for billing reasons, PSTN telephony, while role TMCert1 has the permission to make PSTN telephone calls (and inherits all the permissions of TMPw1, of course). Additionally, the new role hierarchy includes a role TIPwi,i= 1,2, which has the permission to invite new team members, but forbids dropping the project workspace, and a role TICertiwhich 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 pa-rameter. 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 simulta-neously 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)
Table 1.Roles for context-dependent access control
Collaboration Protection Level Environment Role Password Certificate
Project T1 Member TMPw1 TMCert1 Initiator TIPw1 TICert1 Operator TOPw1 TOCert1 Project T2 Member TMPw2 TMCert2 Initiator TIPw2 TICert2 Operator TOPw2 TOCert2
Base Role BPw BCert
start check identity
registered?
no yes
rs=∅ rs=allowedrassignedr((juniorru)))(
activate roles inrs
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 defineIDMSas the set containing the identifiers of identification mechanisms supported by the corresponding collaboration environment.
•assignedr : USERS → 2ROLES,assignedr(u) = {r ∈ ROLES|(u, r) ∈ UA}. The
result ofassignedr(u)is the set of roles for which useruis assigned according toUA.
•juniorr : 2ROLES →2ROLES,juniorr(rs) ={r∈ROLES|rr, r∈rs}. The result ofjuniorr(rs)is the set consisting of all roles which are in a junior inheritance relation to the roles contained in the setrs.
•allowedr :IDMS×2ROLES →2ROLES,allowedr(im, rs) = {subset ofrsauthorized
for im}. Given an identification mechanismim 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. 6.
7.2 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
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 ap-proaches. 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 consider-ing the usage of RBAC in the web context, even if RBAC is assumed to be a promisconsider-ing 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 res-idential 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 environ-ments 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
access in web-based collaboration environments. We have motivated the need for con-sidering context-dependent parameters such as the identification mechanism in the access control decision in web-based collaboration environments. Furthermore, we have mod-eled 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 web-based 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) 281–305
2. Meier, C., Benz, H.: Business process requirements and paradigm of co-operative work: Enhanced Platform. UNITE Project Deliverable (2002) http://www.unite-project.org 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. Security4(2001)
9. Bertino, E., Pagani, E., Rossi, G., Samarati, P.: Protecting information on the web. Comm. of the ACM43(2000)
10. Joshi, J., Aref, W., Spafford, E.: Security models for web-based applications. Comm. of the ACM44(2001)
11. Zapf, M., Reinema, R., Wolf, R., T¨urpe, S.: UNITE — an agent-oriented teamwork environ-ment. In: 4th Intern. Workshop, MATA 2002. Number 2521 in LNCS, (2002) 302–315 12. 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. Security4(2001)
17. Tari, Z., Chan, S.: A role-based access control model for intranet security. IEEE Internet Computing1(1997)
18. Chadwick, D., Otenko, A.: The PERMIS X.509 role based privilege management infrastruc-ture. 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
