Overview of Modern Web Architectures, Standards, Security, and Future Directions

1. Overview of Modern Web Architectures, Standards, Security, and Future Directions Zhenhua Guo 1

2. 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

3. Your current status Friends Activities of your friends photos Video Comment, Rate Aggregationwith Picasa Chat groups More apps! Modern Web App Case Study : Facebook • Facebook • More than 200 million active users • MS paid $240 million for 1.6 percent 3

4. Provider-defined directory Previous Web App Case Study : Yahoo! Directory 4

5. Examples of two “versions” of web apps 5

6. 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 • Sharing, creation of data • Participatory nature • Blogging, commenting, rating • Cooperate, not control • Facebook interoperates with Google Picasa, Yahoo! Flickr, Blogs, etc • User centric • Web is a platform. Users add content (“value”) 6

7. Web 2.0 • Debate (Buzzword vs. Real progress) is going on, but it has begun to coalesce. • “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

8. 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

9. Open Social Javascript API Example Person: ID, NAME, NICKNAME, ADDRESSES, EMAILS, STATUS, MOVIES, MUSIC,FOOD … Activity: TITLE, URL, BODY, PRIORITY … Data Model // 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(); }); Fetch profileinformationof owner JavaScript API example AJAX!!! 9

10. Open Social Message Examples Request (HTTP POST) [{"method" :"people.get", "params" :{ "userId" : ["@owner"], "groupId" : "@self", "id" : "owner", "fields" : ["id","name", "thumbnailUrl", "profileUrl", "id", "displayName"]}}] 157 Bytes How about the corresponding representation in XML??? Response JSON [{"id" :"owner", "data" :{ "displayName" : "Guo Zhenhua" "profileUrl" : "/Main#Profile.aspx?uid=3672642670645936703, "id" : "06881043280087178653", "thumbnailUrl": "http://www.orkut.com/img/i_nophoto64.gif", "name" : { "familyName":"Zhenhua", "givenName":"Guo" }, ...... }}] 10

11. 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 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> </request> XML • Extensible • Support namespace • Support representation of complex data structures. • Heavyweight • Slow and verbose 281 Bytes

12. OpenSocial - Architecture Logic level Components • Interface – REST, Javascript APIs • Client – Ajax, Gadget • Message Format - JSON • Security - OAuth • Data Model 12

13. resource verb 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?

14. 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

15. REST Alternative • SOAP based WS • SOAP Message format • UDDI Service registration • WSDL Service description interface 1 2 3 4 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

16. AJAX

17. 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

18. Data Model

19. OpenSocial Data Model • Define data models for basic objects in social network • Person • Activity • AppData • Relationships between objects can not be represented. • 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)

20. Security in OpenSocial 20

21. 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. • 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? Cartoon by Peter Steiner. The New Yorker, July 5, 1993 issue (Vol.69 (LXIX) no. 20) page 61 21 21

22. SSL/TLS Securer programs + User education Security Requirements (in Web) • Connection level • Confidentiality • Integrity • Non-repudiation • Prevention of replay attack • System Implementation level • Redirect • Session stealing (cookie) • Cross-site scripting, Cross-site request forgery • Architecture level • Authentication • Single Sign-On • Authorization • Delegation 22

23. 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

24. OpenSocial Authorization – OAuth • Motivation • To allow third party apps to access users’ data stored at service provider without requiring username and password. • Solution • Delegated authorization protocol • Light-weight • Explicit user consent • Based on REST • Drawbacks • 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/ 3rd-party App Twitter 24

25. 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 => Identity portability 25

26. 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 • Cross-domain authentication • Attribute exchange beyond authentication • Single Sign-On • Easy OpenID provider switch • Drawbacks • Phishing attack • Resources • Supported by Facebook, Verisign, Sourceforge, Yahoo, etc. http://fcom.us.es/blogs/nuevafcom/files/2008/09/openid-1.jpg 26

27. 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

28. 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

29. Future Directions • Semantic Web (Web 3.0?) • Machine-readable representations of resources and relationships • Artificial Intelligence, Data Mining • Search Engine • Information search • Recommendation System • Scaling • Question Answering • Information retrieval • Social Network Analysis • Flow pattern recognition • Strength of connections 29

30. My Research • Gadget Layout Management • OAuth implementation • Implement 2-legged OAuth • Integrate 3-legged OAuth • PolarGrid Portal

32. Questions?