Building Secure Mashups - PowerPoint PPT Presentation

About This Presentation
Title:

Building Secure Mashups

Description:

Usable Building Secure Mashups D. K. Smetters PARC – PowerPoint PPT presentation

Number of Views:68
Avg rating:3.0/5.0
Slides: 24
Provided by: Diana260
Category:

less

Transcript and Presenter's Notes

Title: Building Secure Mashups


1
Building Secure Mashups
Usable
?
  • D. K. Smetters
  • PARC

2
The promise of Web 2.0
  • Your data, anytime anywhere
  • your friends
  • your family
  • your employer
  • anybody elses you can get your hands on

combined with that of
3
Whats a mashup?
  • Inputs
  • User-generated data
  • often personal user-generated data, such as
    photographs
  • generated by the mashup user and their friends,
    family, favorite presidential canidates, cat,
    neighbors, and so on
  • Social network information
  • another form of private, and even valuable data
  • Public or semi-public data sources
  • databases of available information (e.g. Google
    Maps) with varying guarantees of correctness and
    constraints on use
  • Private data sources
  • e.g. corporate data subject to some form of
    access control, subscription data, etc.
  • Outputs
  • User-focused result (e.g. a visualization)
  • A derived data source
  • input for yet another mashup

4
Goal
  • The goal of all browser/mashup security
    mechanisms is to ensure that
  • The data the user intends
  • Is processed in the way the user intends
  • By the entities s/he chooses
  • Subject to additional constraints imposed by
    others with interest in that data.
  • And nothing else.

5
Why is this hard?
Data Owner
Data Holders
Data Transformation Service
  • Securing mashups requires building systems
    designed for flexible, ad-hoc cross-organization
    delegation of limited access to sensitive data
    all under easy user control.

6
Why is this hard?
Data Owner/User
  • Securing mashups requires building systems
    designed for flexible, ad-hoc cross-organization
    delegation of limited access to sensitive data
    all under easy user control.

7
Approaches
8
Avoid
  • Use only public (or semi-public) data.

9
Embrace
  • All your credentials are belong to us.

10
Reduce it to a previously solved problem
  • Mashup services provided by trusted data holders
    themselves. (Or other sites the user chooses to
    trust.)

11
Looking Under the Lamppost
  • Identify sets of a priori interesting data and
    enable delegation of access to those.

12
Building a Bridge
  • Special privileges, accounts and relationships
    established to enable access to particular data
    for a particular purpose.

13
Outsourcing
  • Identity provider or authorization service
    handles the problem and manages the relationship
    with the user(s).

14
Usability Challenges
15
Who are the users?
  • Mashup developers
  • and the people who build their toolkits, etc.
  • Owners and creators of data to be mashed
  • Administrators of any of the hosts involved
  • End users of resulting mashups

16
Connecting the Providers They Intend
17
Identifying Data
  • Should site www.weasels.com have access to your
    Misc folder?
  • Does it mean the same Misc folder I think it
    means?
  • What did I put in that folder anyway?

18
Specifying Policies
Only members of the finance department can read
the current revenue information. But only if
theyre like, just going to read it. Not if
theyre going to, say, average it against the
public data from other companies in our sector.
Except maybe when it makes us look good. Or when
its my friends, trying to figure out if now is
the time to look for a different job, or..
Only members of the finance department can read
the current revenue information.
Only the people I like can see whether Im going
to the party tomorrow.
19
Making the user an ally
  • How can the user figure out what the system is
    doing (or trying to do)?
  • How can they decide what to do when something
    goes wrong?

This is hard enough when users are face to face
with the site they need to authenticate what
about when its buried in a processing pipeline?
20
Love me, love my mechanism
you cant put any stock in that its not
chrome
I used to use Facebook, but I got off it because
I wasnt happy with their iframe isolation
oh, they have an expired cert, but at least its
ev
21
The Error Attack
As long as configuration errors are common,
attacks can masquerade successfully as errors
and users will be acting rationally if they
ignore them.
22
Whats a developer to do?
the Service Provider MUST inform the User if it
is unable to assure the Consumers true identity.
The method in which the Service Provider informs
the User and the quality of the identity
assurance is beyond the scope of this
specification.
It is assumed that the Consumer has provided its
RSA public key in a verified way to the Service
Provider, in a manner which is beyond the scope
of this specification.
  • Mashup developers are focused on mashing, not
    securing.
  • Will use the easisest mechanism available.
  • Hopefully, thats the right one.
  • Users are at the mercy of the mechanisms chosen
    by the services they want or need to use.

23
Points to Remember
  • Security is a secondary goal
  • People do care. They just care about other things
    more.
  • Dont make them choose
  • They dont care about understanding it in your
    terms.
  • Love me, love my mechanism
  • This stuff is hard for people to understand.
  • After 10 years, people still screw up SSL certs
    more often than not.
  • Whatever you think of SSL, people ought to have
    figured out how to make it easier to manage by
    now. Its not hard to do.
  • Whatever easiest-to-deploy crp option makes it
    through the current fragout will be with us for
    longer than we care to think.
  • The examples used to promote various alternatives
    are way too simple.
  • They dont begin to enable people to evaluate how
    things will work down the road.
Write a Comment
User Comments (0)
About PowerShow.com