Scalable Access Control For Web ServicesGayatri SwamynathanDepartment of Computer ScienceUC Santa Barbara, CA [email protected] Close, Sujata Banerjee, Rick McGeerHP LabsPalo Alto, CA [email protected] Zhao, Kevin AlmerothDepartment of Computer ScienceUC Santa Barbara, CA 93106{ravenben,almeroth}@cs.ucsb.eduAbstractControlling access to a large distributed serviceis a potentially error prone process that may nega-tively impact request throughput and usability. OurAuthorization-Based Access Control (or ABAC) URLrewriter solves this problem by providing locally veri-fiable authorizations and delegation tracking compati-ble with common web tools. Our access control mech-anism is reusable, distributed and meets the scalingrequirements of large distributed services. We demon-strate the successful operation of our proposed mecha-nism on HP’s real-time network monitoring and mea-surement web service, S3.1 IntroductionControlling user access is critical to the success-ful operation and widespread adoption of large-scaledistributed web services. The security framework forsuch services must address the three-fold challengeof user authentication (identity verification), autho-rization (access provided to user) and accountability(monitoring activity and controlling abuse) in order tocontrol user access and prevent distributed-denial-of-service (DDOS) attacks.Access control lists (or ACLs) have remained a pop-ular choice for securing distributed web applicationsdue to their simplicity and ease of application inte-gration. In ACL-based authorizations, a user is au-thenticated by a challenge-response mechanism (suchas passwords or digital certificates) and the request isgranted if the user responds properly to the challengeand possesses access rights to the requested resource.Employing ACL-based authorizations for large-scaledistributed services lends itself to several problems.First, servers or nodes in the system need to either con-tact a central server to determine a users privilege, ormaintain a local ACL. Granting or revoking user ac-cess involves synchronization between all nodes in thesystem. The need for periodic synchronization couldbring the system down in the case of a network parti-tion.Second, as the overall system grows, dependenceon central lists also aggravates the problem of scalabil-ity. ACLs are also known to suffer poor access timesfor large lists. Finally, ACLs are a coarse-grained au-thority mechanism and lack the flexibility to easily im-plement multiple security policies and fine-grained au-thorities.Large-scale distributed web services, consequently,are in need of a robust and scalable access controlsolution. Moreover, in the hands of malicious users,such services make for an effective distributed-denial-of-service tool. In this paper, we present ABAC(Authorization-Based Access Control) URL rewriter, areusable, distributed, capability-based access controlsolution that solves the challenge of securing large-scale distributed services in a highly scalable manner.We implement our capability-based design on S3,HP’s real-time network monitoring and managementweb service comprising hundreds of machines distrib-uted across a geographically dispersed wide-area net-work [3]. Our solution is lightweight with minimalmemory and run-time overheads. Additionally, weemploy only standard web tools to develop our secu-rity solution which proves its quick and easy integra-tion with existing distributed web applications.The remainder of the paper is organized as fol-lows. We discuss the design and implementation of theABAC URL rewriter in Section 2. Next, we analyzeour design and its performance in Section 3. Our con-clusions and future work are presented in Section 4.2 ApproachWe tackle the problem of user authorizations byemploying a capability-based security design. WhileACL-based authorizations permit users to name re-sources and then verify whether users have access tothe identified resource (for example, using password-based schemes), a capability-based approach prohibitsa user from even identifying a resource she does nothave access to. Only users that possess a capability orauthority - an unforgeable pointer to a resource - havethe ability to identify and access a resource.Before discussing the design of our capability-based ABAC URL rewriter on the S3web service, wefirst introduce the operation of S3and present the ob-jectives that drive our design framework for large-scaledistributed services similar to S3.2.1 S3: A Scalable Sensing ServiceS3is a Scalable Sensing Service for real-time mon-itoring and management of large networked systems.S3represents a typical web service comprising hun-dreds of machines distributed across a geographicallydispersed wide-area network. Each machine or serverin the S3infrastructure operates a sensing pod which isa web-service enabled collection of lightweight mea-surement sensors that collect network information atthe machine. Only authorized users of S3are pre-sented the ability to conduct third-party sensing mea-surements between any two machines using uniformresource locators (URLs) that identify the machinesand the sensing service(s) requested.The S3sensing information enables network man-agement components to detect network failure oranomalous behavior, improve path selection, and makenetwork decisions at very fine timescales. Fast re-sponse, consequently, is a critical requirement forusers of the sensing data. Centralized security solu-tions lead to poor response times, and also subvertthe operation of the system in the event of networkpartitioning. Access control should also scale easilyto integrate the addition of new users and measure-ment servers to the system. Finally, user authoriza-tions need to be fine-grained to accommodate variouspolicy specifications.2.2 ObjectivesThe design of the ABAC URL rewriter is guidedby several goals that are necessary requirements for asuccessful access control mechanism.• Decentralized: A server must continue process-ing requests correctly, even if under network par-tition.• Efficient: The mechanism must not adversely im-pact request throughput.• Lightweight: Both server and client deploymentcosts must be minimal and must integrate wellwith existing web tools, such as web browsers.• Open: The solution must facilitate and managethe inclusion of additional users, servers, and ser-vices.• Extensible: The mechanism must support the ex-pression of additional access