Please Permit Me : Stateless Delegated Authorization in MashUps

Please Permit Me: Stateless Delegated Authorization in MashUps Ragib Hasan*, Richard Conlan+, Brian Slesinsky+, NandakumarRamani+, Marianne Winslett* *University of Illinois at Urbana-Champaign +Google Inc. Annual Computer Security Applications Conference (ACSAC) 2008

In the Beginning … • There were websites … • Craigslist, Google Maps, Citibank, BankofAmerica • And we logged into them individually • But then, people needed to combine data from multiple sources

Combining Data/services in the Web • MashUps are hybrid web applications that • Combine data/services from more than one source • Are put together rapidly • Are often created by third parties • MashUps have proliferated in the web • Thousands of MashUps designed so far [Programmableweb.com] • Growing by 100+ MashUps per month • Google, Yahoo!, Microsoft, IBM have support for building MashUps fast [e.g. Google Mashup Editor]

Example MashUp • HousingMaps.com – combines data from Google Maps and Craigslist • Informative MashUp, no authorization needed • Mint.com/Yodlee.com – Personal finance MashUp – aggregates data from online bank account and credit card services, provides budgeting and other financial tools • User data aggregator, requires authorization to fetch data

Authorization in MashUps • Authorization is done by handing over passwords to the user Alice registers at the MashUp, and provides her login/password for the web sites The MashUpimpersonates Alice and uses the login/password to access back-end services and fetch data MashUp Alice directly accesses the websites (separately) using her login/password Service/Website

Problems • Complete trust of MashUp • We have to give out our login/password • MashUp server compromise can leak the info • Phishing is also another threat • Authorization is perpetual – once given to MashUp, it can only be revoked by changing it at the backend • Coarse-grained access • Access is all-or-nothing • No way to specify what level of access we will allow for the MashUp • No delegation model • Users cannot specify if the authorization can be delegated in full or partially

Our Goal • To create a practicalauthorization scheme for MashUps • Without extensive state maintenance • Allowing fine grained delegation of authorization • Allowing sub-delegation of authorization • Without leaking authorization secrets to the MashUp

Authroization approaches • MyProxy, X.509, Globus Delegation service • No way to limit the rights during delegation • KeyNote/PolicyMaker, SPKI/SDSI • Allows rights restriction, but applicable to environments with PKI authentication, schemes usually not used in username/password based auth in websites • Not widely used in practice, no infrastructure or practical deployment in the Web

Recent work • AuthSub: Authorization protocol for Google services • Requires registration of front-end and back-end services • Server needs to maintain state of issued tokens • Limited number of tokens per user/app, (10 in current version) • Only allows coarse-grained authorization • OAuth: New scheme for “open authorization” • Allows access delegation • Requires stateful server • Tokens are single use only

Our Goal • To create a practical authorization scheme for MashUps • Without extensive state maintenance • Allowing fine grained delegation of authorization • Allowing sub-delegation of authorization • Without leaking authorization secrets to the MashUp • Solution: Delegation Permits • Contribution: • Design and implement a complete system of Permit-based authorization in MashUps • Use existing web technology

Talk outline • The world of MashUps • MashUp Authorization • Approaches • Problems • Delegation Permits • Composition • Protocol • Attack analysis

Delegation Permits Idea: In real life, people issue permits to allow someone else have specific access to their services Allow Bob to enter my office only once for 5 minutes, and only retrieve a file

Delegation Permits • Permits are unforgeable, limited-lifetime digital tokens • Holding a permit is sufficient to gain access to a service • Users can select what access rights they will grant to the MashUp

Delegation Permits: Structure • Permit Structure • User id • MashUp • Back-end service • Group ids • Permit descriptor(s) • Timestamps • Signature

Permit Descriptors • Permit Descriptors are specified as free form strings, with their meanings at the discretion of the back-end service • E.g., descriptor for read-only service can be READ, RD_ONLY etc.

Delegation Permits • Services advertise their permit descriptor strings and associated access levels, and a human-readable explanation for the descriptor • MashUps that want to use the back-end service request the user to grant permits • Back-end services grant access when presented with a valid, unexpired permit • No state needs to be retained in the back-end services

Delegation Permits • Permits can be further sub-delegated • A permit descriptor READ*/WRITE* can be sub-delegated as • READ, WRITE, READ/WRITE, READ*, WRITE*, READ*/WRITE, READ/WRITE*, READ*/WRITE*

Access delegation MashUps get the advertised Permit Descriptors for back-end services Prompts user for required permits for this MashUp Grants some or all of requested permits Uses the permits to access back-end services

System model • Permit Grant Service • Prompts user for requested permits • Issues permits based on user choice • Permit History Service • Shows permits issued by a particular user • Allows limited revocation through removal of permits at the user’s side • Permit Handler Module • Part of MashUp, used to handle permits, store and retrieve permits from browser cookies • Client-side Handler Module • Used by back-end services • Advertises permit descriptors • Handles permits and access to services

Permit Grant Protocol 5.User selects permits and sends choice to PGS 9. Mashup sends request along with permits, to back-end service PGS 10. Back-end service verifies the permit, and provides the proper level of authorization to the mashup 4.PGS prompts the user with permit issue page 6.PGS creates the permits, and sends them to user 3. User redirects to the PGS 1. User logs into the mashup User (browser) Mashup Back-end service Permit handler 8. Permit handler stores the permits in a cookie and redirects user to the mashup 11. After getting data from back-end, mashup integrates it with data from other back-ends, and sends to user 2. Mashup sends redirect to PGS with required permit info 7. User redirects to Permit handler along with the permits

Attack resistance • Malicious/Compromised MashUps • Permits are stored as client-side cookies, so previous permits are not leaked • Even if permits are cached by MashUp, their limited lifetime limits window of vulnerability • A compromised/malicious MashUp can only use the privilege granted in a permit, and nothing further • Denial of service by attacking the PGS • Have multiple PGS along with load-balancing

Attack Resistance • Intercepting permits in transit • Use SSL to communicate between components • Compromise of user machine • Use session cookies to store permits

Other issues • Tradeoff between usability and security • Permit lifetimes should be short to reduce the attack window • But prompting users too frequently may reduce usability of system • User awareness • Users should be made aware of the permissions they are granting, and implications

Implementation • Implemented in Java 1.5 • Multiple PGS • Complete server and client access libraries implemented

Discussion • We designed a permit-based delegation scheme for MashUp authorization • A full implementation using Java is provided • Revocation is limited, and in some cases, revocation of permits is not handled other than making timestamps short

Questions? Ragib Hasan Department of Computer Science University of Illinois at Urbana-Champaign www.ragibhasan.com rhasan@uiuc.edu

Please Permit Me : Stateless Delegated Authorization in MashUps