Presentation Transcript

1. 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
2. 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
3. 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]
4. 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
5. 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
6. 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
7. 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
8. 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
9. 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
10. 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
11. Talk outline The world of MashUps MashUp Authorization Approaches Problems Delegation Permits Composition Protocol Attack analysis
12. 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
13. 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
14. Delegation Permits: Structure Permit Structure User id MashUp Back-end service Group ids Permit descriptor(s) Timestamps Signature
15. 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.
16. 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
17. 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*
18. 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
19. 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
20. 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
21. Example Permit permit_v1|uid=testuser|g=uiuc|s=mycoolapp.com/|ds=MyCoolMashUp|pd=MyBugTrackerReadOnly|lt=2007022912000|pt=2007022912000|at=2007022912000|alg=DSA|kid=FOO|sig=B64ENCODEDDSASIG|
22. 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
23. Attack Resistance Intercepting permits in transit Use SSL to communicate between components Compromise of user machine Use session cookies to store permits
24. 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
25. Implementation Implemented in Java 1.5 Multiple PGS Complete server and client access libraries implemented
26. 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
27. Questions? Ragib Hasan Department of Computer Science University of Illinois at Urbana-Champaign www.ragibhasan.com rhasan@uiuc.edu