please permit me stateless delegated authorization in mashups
Skip this Video
Download Presentation
Please Permit Me : Stateless Delegated Authorization in MashUps

Loading in 2 Seconds...

play fullscreen
1 / 27

Please Permit Me : Stateless Delegated Authorization in MashUps - PowerPoint PPT Presentation

  • Uploaded on

Please Permit Me : Stateless Delegated Authorization in MashUps. Ragib Hasan * , Richard Conlan + , Brian Slesinsky + , Nandakumar Ramani + , Marianne Winslett * * University of Illinois at Urbana-Champaign + Google Inc .

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'Please Permit Me : Stateless Delegated Authorization in MashUps' - amos

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
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
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
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 []
    • Growing by 100+ MashUps per month
    • Google, Yahoo!, Microsoft, IBM have support for building MashUps fast [e.g. Google Mashup Editor]
example mashup
Example MashUp
  • – combines data from Google Maps and Craigslist
    • Informative MashUp, no authorization needed
  • – 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 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


Alice directly accesses the websites (separately) using her login/password


  • 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
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
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
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 goal1
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
Talk outline
  • The world of MashUps
  • MashUp Authorization
    • Approaches
    • Problems
  • Delegation Permits
    • Composition
    • Protocol
  • Attack analysis
delegation permits
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 permits1
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
Delegation Permits: Structure
  • Permit Structure
    • User id
    • MashUp
    • Back-end service
    • Group ids
    • Permit descriptor(s)
    • Timestamps
    • Signature
permit descriptors
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 permits2
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 permits3
Delegation Permits
  • Permits can be further sub-delegated
  • A permit descriptor READ*/WRITE* can be sub-delegated as
access delegation
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
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
Permit Grant Protocol

5.User selects permits and sends choice to PGS

9. Mashup sends request along with permits, to back-end service


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)


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

example permit
Example Permit


attack resistance
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 resistance1
Attack Resistance
  • Intercepting permits in transit
    • Use SSL to communicate between components
  • Compromise of user machine
    • Use session cookies to store permits
other issues
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
  • Implemented in Java 1.5
  • Multiple PGS
  • Complete server and client access libraries implemented
  • 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

Ragib Hasan

Department of Computer Science

University of Illinois at Urbana-Champaign

[email protected]