Applying Role-Based Access Control toCollaborative Web PortalsSteven A. DemurjianUniversity of Connecticut371 Fairfield WayStorrs, CT [email protected] RenUniversity of Connecticut371 Fairfield WayStorrs, CT [email protected] BerheUniversity of Connecticut371 Fairfield WayStorrs, CT [email protected]. DevineniSerebrum Cooperation555 US Highway Route 1Iselin, NJ [email protected]. KoppartiSerebrum Cooperation555 US Highway Route 1Iselin, NJ [email protected]. PolineniSerebrum Cooperation555 US Highway Route 1Iselin, NJ [email protected] portals are emerging as a viable technologyto allow groups of individuals to easily author, create, up-date, and share content via easy-to-use web-based interfaces.Freeware and open source products (e.g., SourceForge’s Me-diaWiki) as well as commercial solutions (e.g., Microsoft’sSharepoint) are prevalent in today’s marketplace. From asecurity perspective, these products are often very limitedand coarse grained in both their authorization and authenti-cation. For example, in the case of Wikis, the security modelranges from anonymous users (no authorization and limitedaccess) to the feature-rich system via registration with rigidroles, super users, and read-only browser. In the latter case,once access via registration is granted, that access is oftenthe full range of actions and capabilities that are available inthe Wiki. However, in practice, such full access may not beappropriate for all applications, particularly as the collabo-rative technology moves into other domains such as healthcare (which have stringent HIPAA requirements). In thispaper, we report on our research and development effort ofa hierarchical role-based access control for collaborative webportals that encompasses and realizes security at the appli-cation level, the document level (authoring and viewing),and the look-and-feel of the portal itself.Categories and Subject DescriptorsH.4 [Collaborative Web Portals,]: Miscellaneous; D.2.8[Access Control Models]: [Security Administration]Securityand ProtectionKeywordsRBAC, Wiki, Access Control DesignPermission to make digital or hard copies of all or part of this work forpersonal or classroom use is granted without fee provided that copies arenot made or distributed for profit or commercial advantage and that copiesbear this notice and the full citation on the first page. To copy otherwise, torepublish, to post on servers or to redistribute to lists, requires prior specificpermission and/or a fee.Copyright 200X ACM X-XXXXX-XX-X/XX/XX ...$5.00.1. INTRODUCTIONOver the past decade, the World Wide Web (WWW) hascome to the forefront as a viable means to allow individualsand organizations to collaborate. As a result, web portalshave emerged as a means to facilitate these interactions, formany different purposes, ranging from information reposi-tories to full-fledged authoring and document collaboration.For instance, Web sites like WebMD (www.webmd.com) andWikipedia (www.wikipedia.org) are utilized by unregisteredusers to browse existing content on an array of differenttopics via easy-to-use web-based interfaces. At the otherend of the spectrum, for registered users, these web por-tals provide a means to author, create, modify, and trackdocuments of all types within a consistent framework or in-frastructure. A registered user of Wikipedia has the abilityto create new document content and modify existing con-tent. In fact, freeware and open source products such asSourceForge’s Mediawiki or a commercial solution such asMicrosoft’s Sharepoint allows any individual with sufficientexpertise to generate their own web portal to meet specificpurposes and needs.However, from a security perspective, these products areoften very limited in the level of protection that is offered toinformation content that is created and uploaded to thesevarious sites. For example, a registered Wikipedia user couldcreate and upload intentionally erroneous content (e.g., adocument that says that the world is flat). Some of theseweb sites depend on the community of users themselvesto monitor document content; as the volume of contentat these sites grows, it becomes problematic to attemptto maintain this information in this fashion. In addition,many corporate and governmental users are hesitant to uti-lize such technologies for information content and collabo-ration, restricting their usage to an information repository.For example, consider health care, where there are stringentHIPAA (www.hhs.gov/ocr/hipaa/) requirements regardingthe security of health care data. In order to utilize a webportal or Wiki to allow clinical researchers to collaborateon studying diabetes in a patient population, there wouldneed to be much more rigorous security requirements thanthe coarse-grained authorization and authentication (usernames/passwords) that are typically offered by Wikis/webportals.In this paper, we report on our research and developmenteffort of applying role-based access control (RBAC) to webportals as part of a funded research effort [19] for collabo-rative software requirements elicitation [21]. In this effort,the Axon Wiki has been prototyped with RBAC securityat the application level, the document level (authoring andviewing), and the look-and-feel of the portal itself. Axon isa Java-based, Ajax (developers.sun.com/ajax) Wiki that istargeting enterprise adoption by offering a wide range of doc-ument authoring, collaboration, publishing, versioning, andother capabilities. The intent is to provide a full-capabilityWiki that has fine-grained RBAC that meets the require-ment in terms of security requirements, flexibility and ad-ministration so that it is more suitable than open source andother commercial products.The remainder of this paper is organized into 5 sections.Section 2 explains background concepts on the Axon Wikiincluding its capabilities and architecture. Using this as abasis, Section 3 details security assumptions and concepts,that while specific to Axon, can be generalized to collabora-tive Web portals. Section 3 also includes a detailed discus-sion of the permissions that support RBAC/security at theapplication level, the document level (authoring and view-ing), and the look-and-feel of the Wiki itself. Section 4 de-scribes the set of relational database tables that are utilizedto realize the permissions given in Section 3; these tablesare