1 / 32

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

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

orrin
Download Presentation

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

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

  31. Questions?

More Related