Overview of Modern Web
Architectures, Standards, Security,
and Future Directions
Zhenhua Guo
1
Outline



Web App Case Study
Modern Web Characteristics
Modern Web Architecture : Open Social



Architecture
Components
Security




Background
Authorization
Out of Scope: Authentication
Future Directions
2
Modern Web App
Case Study : Facebook
Your current status

Friends
photos
Facebook


More than 200 million active users
Activities of
MS paid $240 million foryour
1.6friends
percent
Video
Comment, Rate
Aggregation
with Picasa
groups
Chat
More apps!
3
Previous Web App
Case Study : Yahoo! Directory
Provider-defined directory
4
Examples of two “versions” of web apps
1995-2005 Web
2005-Present Web
Britannica Online
Wikipedia
Akamai
BitTorrent
Directories
(Taxonomy)
Tagging
(Folksonomy)
Tightly coupled apps
App Mashup/Integration
Home page
Blog
5
Web 2.0


“Second generation of web development and web
design”
Web 2.0 vs. Web 1.0

Technical point of view



Similar technologies as Web 1.0: HTML, Javascript, XML, HTTP, etc.
Web2.0 makes the web programmable
User’s point of view

Read-write collaborative web


Participatory nature


Blogging, commenting, rating
Cooperate, not control


Sharing, creation of data
Facebook interoperates with Google Picasa, Yahoo! Flickr,
Blogs, etc
User centric

Web is a platform. Users add content (“value”)
6
Web 2.0
Enterprise Approach
Web 2.0 Approach
Portlets
Gadgets, Widgets
SOAP
RSS, Atom, JSON
WSDL
REST(GET, PUT, POST ,DELETE)
Workflow managers
Mash-ups (e.g. Yahoo Pipes)
Server side integration Client-side integration (AJAX)
Gateways

Debate (Buzzword vs. Real progress) is going on, but it
has begun to coalesce.



User-centric social network portals
“Web 2.0 Architectures: What entrepreneurs and information architects
need to know”
OpenSocial: case study that illustrates or motivates several Web 2.0
topics of discussion.
We will use Open Social to illustrate Web 2.0 architecture
7
OpenSocial

A coherent open architecture designed for
social network services and applications.

Common APIs across many websites




REST/RPC protocols – for server-to-server interactions
Javascript APIs – for browser-to-server interactions
Authorization mechanism, Data model …
Usage

Supported by MySpace, Google Orkut, Twitter,
LinkedIn, XiaoNei…


Internationalization
Rival: Facebook
8
Open Social Javascript API Example
Data
Model
Fetch profile
information
of owner
JavaScript
API
example
AJAX!!!
Person: ID, NAME, NICKNAME, ADDRESSES, EMAILS,
STATUS, MOVIES, MUSIC,FOOD …
Activity: TITLE, URL, BODY, PRIORITY …
// Creates a data request object to use for
// sending and fetching data from the server.
var req = opensocial.newDataRequest();
// Adds an item to fetch data from the server
req.add(req.newFetchPersonRequest('OWNER'), “owner”);
// Sends a data request to the server
req.send(function(data) {
owner = dataResponse.get("owner").getData();
});
9
Open Social Message Examples
Request (HTTP POST)
157 Bytes
[{"method" :"people.get",
"params" :{
"userId" : ["@owner"],
How about the corresponding
"groupId" : "@self",
representation in XML???
"id"
: "owner",
"fields" :
["id","name", "thumbnailUrl", "profileUrl", "id", "displayName"]}}]
JSON
[{"id"
:"owner",
"data" :{
"displayName" :
"profileUrl" :
"id"
:
"thumbnailUrl":
"name"
:
...... }}]
Response
"Guo Zhenhua"
"/Main#Profile.aspx?uid=3672642670645936703,
"06881043280087178653",
"http://www.orkut.com/img/i_nophoto64.gif",
{ "familyName":"Zhenhua", "givenName":"Guo" },
10
Request message
represented in XML
<request>
<method>people.get<method>
<params>
<userId>
<id>@owner</id>
</userID>
<groupId>@self</groupId>
<id>owner</id>
<fields>
<field>id</field>
<field>name</field>
<field>thumbnailUrl</field>
<field>profileUrl</field>
<field>id</field>
<field>displayName</field>
</fields>
<params>
281 Bytes
</request>
JSON






Lightweight, Simple
Can represent basic data structures
(number, string, boolean, object, array)
Textual human-readable
Easy to generate and manipulate
Not extensible, No namespace
Hard to represent complex data structures
 References
 User-defined type
XML





Extensible
Support namespace
Support representation of complex
data structures.
Heavyweight
Slow and verbose
OpenSocial - Architecture
Components





Interface –
REST, Javascript APIs
Client – Ajax, Gadget
Message Format - JSON
Security - OAuth
Data Model
Logic level
12
OpenSocial Interface – REST
REST – REpresentational State Transfer
 Based on HTTP (client/server + stateless server)
 Resource-oriented (resource can be anything)
 Each resource is identified by a unique URL
 State transition (Link resources together)
 Resources have multiple representations (json, xml)
 Uniform interfaces
How to access top ten Twitter topics?
GET
Read
resource
verb
POST
PUT
DELETE
Create
Update
Delete
GET http://search.twitter.com/trends.json
Returns the top ten topics
that are currently trending on Twitter.
13
Analysis of REST

Treat the web as a big database of resources



Good for CRUD operations
A strong constraint – Stateless
Beyond REST

Stateful applications



Streaming Applications
Workflow Execution
Push-Based systems

Pub-Sub systems
14
REST Alternative

SOAP based WS

SOAP
Message format

UDDI
1
2
3
Service registration

WSDL
4
Service description interface
Publish – Find – Bind


About 60 core ws-* protocols
Designed for server-server interactions


SOAP and WSDL are really complicated
Browser-based apps are second-class
citizens.
15
AJAX
OpenSocial Client Tech – AJAX

Rationale
Update sections without refreshing the whole page
 More interactive
 More responsive
 Less bandwidth usage

Asynchronous JavaScript and XML





HTML + CSS  Presentation
DOM  Document model (for dynamic manipulation)
XMLHttpRequest  Asynchronous Communication
JSON/XML  Data format
Javascript  Bring these together
17
Data
Model
OpenSocial Data Model

Define data models for basic objects in social
network




Relationships between objects can not be
represented.



Person
Activity
AppData
Friend of a Friend (FOAF) – Based on W3C RDF
XHTML Friends Network (XFN)
Other possible issues




Groups, roles, communities
Strength of relationships
Relationships in which more than two objects are involved
Scalability (in terms of number of friends)
19
Security in OpenSocial
20
Beyond Functionalities - Security

Identity



“On the internet, nobody knows you're a dog”
Claimed Identity ≠ Real Identity
Data protection


Who can access your Facebook data?
Increasing risk of identity theft and impersonation.




Cartoon by Peter Steiner.
The New Yorker, July 5, 1993 issue
(Vol.69 (LXIX) no. 20) page 61
Favorite color, mother’s maiden name, …
“Friends” and applications have access to this
“Predicting Social Security numbers from public data”
Communication links
Messages are passed by intermediary machines
 Intermediaries understand your messages?
 Intermediaries alter your messages?
 Intermediaries forge your messages?
21
Security Requirements (in Web)

Connection level





SSL/TLS
System Implementation level




Confidentiality
Integrity
Non-repudiation
Prevention of replay attack
Redirect
Session stealing (cookie)
Cross-site scripting, Cross-site request forgery
Securer programs +
User education
Architecture level

Authentication


Single Sign-On
Authorization

Delegation
22
Challenges

Technical Challenges





Loosely coupled components
No single, isolated trusted base
Domain-specific policies
Separation of security policies and security mechanisms.
Possible solutions

Authentication




Central Authentication Service
Cosign
OpenID
Authorization


Shibboleth
OAuth
23
OpenSocial Authorization – OAuth

Motivation


Solution





Delegated authorization protocol
Light-weight
Explicit user consent
Based on REST
3rd-party App
Twitter
Drawbacks




To allow third party apps to access users’ data stored at service
provider without requiring username and password.
Vulnerable to session fixation attack (http://oauth.net/advisories/2009-1)
Delegation granularity (Service provider-specific)
Access token expiration and revocation
Resources

http://oauth.net/
24
Authentication


OpenSocial does not define authentication mechanism.
Different accounts for different service providers



Twitter, Facebook, Myspace, Orkut, Hi5 …
Same data everywhere
Account linking
Linking Disparate Account IDs Across Multiple Systems or Applications
Identity
Federation
Web
Server
Identification
Provider
Web
Server
Web
Server
N
W
Web
Server
E
S
Trust
Relationship
Web
Server
=>Identification
Identity portability
Web
Server
Provider
25
Authentication – OpenID

Motivation


Provide lightweight authentication service across domains
Solution
Users are asked to prove ownership of their OpenID identifiers.
 OpenID identifiers are URLs (e.g. http://zhenhua-guo.blogspot.com).
 Service provider and identity provider are clearly separated.
 Authentication delegation (service provider → identity provider)

Advantages





Drawbacks


Cross-domain authentication
Attribute exchange beyond authentication
Single Sign-On
Easy OpenID provider switch
Phishing attack
Resources

http://fcom.us.es/blogs/nuevafcom/files/2008/09/openid-1.jpg
Supported by Facebook, Verisign, Sourceforge, Yahoo, etc.
26
OAuth and OpenID




Based on relaxed REST
Use SSL/TLS to guarantee confidentiality,
integrity and non-repudiation.
Scalability
Vulnerable to



Phishing
Cross-site scripting
Cross-site forgery request
27
Conclusions



Adoption of web 2.0
Services, not packaged software
Open Architecture and Open Standards





Interoperability
Flexibility
Integration
Security
Adoption in scientific communities

Traditional gateways


LEAD, Earth System Grid
Gateways that integrate web 2.0 technologies



myExperiment, SciVee, Sakai
Open Life Science Gateway
PolarGrid Portal
Future Directions

Semantic Web (Web 3.0?)


Machine-readable representations of resources and
relationships
Artificial Intelligence, Data Mining

Search Engine


Recommendation System


Scaling
Question Answering


Information search
Information retrieval
Social Network Analysis


Flow pattern recognition
Strength of connections
29
My Research

Gadget Layout Management

OAuth implementation



Implement 2-legged OAuth
Integrate 3-legged OAuth
PolarGrid Portal
Questions?