• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Cloud Computing2
 

Cloud Computing2

on

  • 961 views

 

Statistics

Views

Total Views
961
Views on SlideShare
961
Embed Views
0

Actions

Likes
0
Downloads
5
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Cloud Computing2 Cloud Computing2 Presentation Transcript

    • AJAX in the Cloud AJAX Database Programming Brent Hamby & Geoff Hendrey October 21st 2008
    • Agenda In this talk we will cover 3 important questions: 1. What are today's options for cloud databases, and why can't they be easily accessed by pure JavaScript APIs? 2. What are the gaps between the Web 1.0 database security model, and the unforgiving JavaScript environment? 3. How can we create a new AJAX/RIA security paradigm for Database as a Service (DaaS)?
    • The Journey Who we are • From LBS industry • Building mapping web apps in the old days o huge time and development costs o complex geographic information systems o poor user interfaces • Google Maps: the inspiration of the AJAX revolution o Object Oriented JavaScript API's o Faster, Cheaper, Better apps o initial resistance from big GIS.  haters • Gave birth to the Mash-up application paradigm
    • Our mission Apply lessons of the Google maps revolution to Database in the cloud Our project: NextDB.net : the hosted AJAX Database
    • The Cloud Computing Landscape Establishing a vocabulary: 1. CLOUD SERVERS 2. CLOUD VOLUMES 3. CLOUD APPLICATION FRAMEWORKS 4. CLOUD DATABASES
    • Cloud Servers General purpose operating systems and execution environments Trends: • virtualization • provisioning tools • elasticity (ability to add servers to respond in near real-time offered loads) Examples: • GoGrid • EC2 • Flexiscale Conclusion: Hosted virtualized servers could be used to deploy a database, but a virtual server is not a Cloud Database
    • Cloud Volumes • Behaves like a block device • Install filesystem on top of it • Survives indepently of the virtual server • Amazon Elastic Block Storage (EBS) is the primary example Conclusion: hosted volumes could be used as storage for database files, but the hosted volume is not in-and-of-itself Cloud Database
    • Cloud Application Frameworks A database systems coupled to an application framework. Hosted App Frameworks Have been around forever -think Tomcat + MySQL Web Hosting Why aren't they Cloud Application Frameworks? -maybe they are -but if they are not, it's because they lack SCALABILITY -limited to a slice of resources on a single server Examples of new generation of Cloud Application Framework -Google App Engine -Combines Python Web 1.0 application scripting with BigTable -Concusion: Not a Cloud Database, although your application in the cloud can access a database in the cloud
    • Cloud Databases databases with an API that can be accessed over the web Amazon Simple Storage Service (S3) -provides a bucket service (e.g. hashmap) -can be accessed from any secure server that can sign its request Amazon SimpleDB -provides a structured data model -An Amazon SimpleDB domain is like a worksheet, items are like rows of data, attributes are like column headers, and values are the data entered in each of the cells. -same security model as SimpleDB Conclusion: S3 cannot be considered a database by most modern definitions. SimpleDB is a Hierarchical Cloud Database. Neither is a Relational Cloud Database.
    • Can I Access SimpleDB or S3 from an AJAX/RIA? • The AWS security model is based on Secret Keys and Digital Signatures • The Secret Key is used to sign all messages sent from the client to the server, along with the key ID. • The Server looks up its copy of the secret key using the Key ID, and checks the signature • This model implicitly relies on the ability of the message signer to keep the key safe.
    • Secret Keys and Digital Signatures Rule #1 of AWS security: Secrets must be ....secret quot;Your Secret Access Key is a secret, which only you and AWS should know. It is important to keep it confidential to protect your account. Store it securely in a safe place...To provide proof that you truly are the sender of the request, you also include a digital signature calculated using your Secret Access Key.quot; Rule #1 of AJAX security: There are no secure AJAX clients Nothing can possibly be digitially signed or hashed by a JS application because the secret key itself would be compromised
    • So how can I access SimpleDB or S3 from a RIA/AJAX You must build a serverside application to act as a secure proxy between the client and AWS: 1. formulate and sign AWS requests without compromising the key 2. validate the identity (username/pwd) of your application end user via a query to SimpleDB or S3 3. implement Web 1.0-style application logic to control application behavior based on user's identity established in step 2 Would the Google Maps Mash-up revolution have happened if you had to write the server side component? (no... obviously)
    • The Paradox The RIA/AJAX paradigm relies on a Web 1.0 serverside architecture for accessing secure resources such as a database. To understand how to move Cloud databases forward, and eliminate the serverside application, we have to start by going backward, to understand what is broken in the RDBMS security model.
    • The RDBMS Security Model The modern Relational Database Management System (RDBMS) is knows as a quot;client-serverquot; database architecture with a security model designed before the advent of the Web. The notion of quot;clientquot; in this context was conceived under the following constraints that DO NOT HOLD for AJAX/RIA: • clients are typically secured behind the same firewall, and reside on the same LAN (or virtual network) as the server • client are authenticated via the RDBMS's notion of users and roles (quot;scott/tigerquot;...anyone...anyone) • clients, in reality, are trusted applications • because clients are trusted applications, they are free to execute ad-hoc SQL
    • Can we apply the RDBMS client/server model over the web? NO! • To apply the RDBMS client-server model, you need a trust relationship with every end-user of the application, and an associated user/role in the RDBMS. That's just ridiculous! (it's table-level security at best, not row-level security) • Since you can't create an RDBMS user/role for application end users, you will get hacked: o Sensitive data will be stolen (SELECT * FROM USER) o Your system will get wiped out (DELETE FROM USERS)
    • Identity and Security One of the cornerstones of the relational database model is the concept of identity. “Identity” is a familiar concept to everyone who owns a credit card (the credit card number is the card's “identity”). Another for of identiy is a Social Security Number (SSN) that identifies you as a United States Citizen. “Identity” is simply a value that is used to keep track of data. Rows in a database table typically have an identity defined by the row's primary key (PK). If your Social Security Number or credit card number is stolen it can be impossible to “put the genie back in the bottle”. Similarly, if a Primary Key is accessible to an application, or malicious user, it can be saved and used for malicious purposes, like changing the price of a product, or altering data that should be secure.
    • The Role of the Primary Key In a Web 1.0 serverside RDBMS application, primary keys act as a common currency between the serverside application and the database. Primary keys and foreign keys form a relationship graph connecting rows in the database. Primary keys are a natural mechanism for traversing this graph: SELECT * FROM ACCOUNT WHERE FK_TO_USER = 19
    • The dialog between the serverside application and the database app: quot;give me the primary key for USER johndoe/abc123quot;(SELECT PK FROM USER WHERE NAME='johndoe' AND PWD='abc123') database: quot;19quot; app: quot;give me the account information corresponding to the user identified by PK 19quot; (SELECT * FROM ACCOUNT WHERE FK_TO_USER=19) As we can see from the dialog above that the database will blindly return the raw identity for the user (think SSN), for any primary key. Therefore, the security/integrity of this dialog cannot be maintained if the application code can be tampered, or ad-hoc values can be sent to the database.
    • Primary Keys Won't Work For AJAX/RIA Primary Key is an insecure mechanism for identifying rows between a server and an AJAX/RIA (or any browser-based application).The following is to state the obvious. primary keys are typically auto-incrementing surrogate keys o divulges hints about number of rows in a table o can be altered (primary key quot;mathquot;, like quot;pointer mathquot;) to affect malicious results o http://bank.com?action=viewbalance&accountPK=2359 o hmm...how about I change 2359 to 2360? Will I see someone else's account balance? For these reasons, nobody in their right mind would pass primary keys back and forth between a web client and server.
    • So Are We Stuck With The Serverside App? No (as we will see later). And there are many good ideas we should carry forward from the relatively secure Web 1.0 style of programming: 1. Never allow the client to formulate ad-hoc queries 2. Prevent injection attacks by parameterizing queries 3. Never return primary keys to the browser
    • The Missing Piece? A Web-safe alternative to the primary key that: 1. is fundamentally secure in a web client-server architecture 2. preserves the semantics of quot;dialogquot; between client and server 3. is retrieved directly from the database What we need is a Secure Unique Result Identifier (SURID).
    • Introducing the SURID Nextdb.net's web-safe alternative the PK One SURID is generated by the database for each row returned to the AJAX/RIA client, according to this algorithm: base64Encode( cipher( TABLENAME + PK + ACCESS_CONTROL+ MESSAGE_DIGEST)) • base64Encode function: converts binary to text for transport in JSON. • ciper function: performs strong encryption using a private key
    • Anatomy of the SURID • TABLENAME: the name of the table from which the row data was retrieved (in the case of data joined from multiple tables, multiple SURIDs are returned) • PK: the actual primary key of the data • ACCESS_CONTROL: dynamically generated rules which define if UPDATE or DELETE operations can be applied to data identified by a SURID • MESSAGE_DIGEST: SHA-1 or MD5 digest (detects tampering)
    • Example using SURID Considering the following rules for a hypothetical application: 1. A user may query his account profile 2. A user may update his account profile 3. A user may NOT delete his account profile
    • Dialog Between AJAX/RIA and DaaS AJAX/RIA: quot;give me the ACCOUNT row and SURID for jdoe/abc123quot; DaaS:quot;here is the JSON for this USER {nickName:quot;john doequot;, userName:quot;jdoequot;, email:quot;jdoe234@gmail.comquot; PK:quot;dj38f3cvcvrn3z4egr434b469rtg3sss3rewesquot;}quot; AJAX/RIA: quot;UPDATE the nickName column to quot;johnnyBoyquot; for PK:dj38f3cvcvrn3z4egr434b469rtg3sss3rewesquot; DaaS: I decrypted the SURID and checked its digest. It is valid, and its ACCESS_CONTROL allows UPDATE. I will perform the requested operation.
    • Moving from dialog to actual JS code var connection = new net.nextdb.Connection(quot;anAcctquot;, quot;aDBquot;); var query = new net.nextdb.Query(quot;loginquot;); query.params = {name:quot;jdoequot;, pwd=quot;abc123quot;}; connection.executeQuery(q, function(rows, error){ alert(quot;login succeeded.quot;); var update = new net.nextdb.Update(quot;USER_TABLEquot;); update.setParameters(nickname:quot;johnnyboyquot;); update.setRowId(rows[0].TABLE1.PK);//use SURID conn.executeUpdate(update, function(key,error){ alert(quot;update succeededquot;); }); });
    • Important! In the previous code snippet, there is NO serverside code needed. the SURID moves freely over the web, exchanged back and forth between the AJAX app and the Daas without compromising security.
    • Security Hole? What prevents a hacker from inserting this code with a debugger and violating rule 3, quot;A user may NOT delete his account profilequot;? var del = new net.nextdb.Delete(quot;USER_TABLE); del.setRowId(rows[0].TABLE1.PK); connection.executeDelete(del, function(key, error){ if( ! error){ alert(quot;My hack worked! I broke the rules!quot;); }else{ alert(quot;My hack failed.quot;); } });
    • SURID Access Control The ACCESS_CONTROL bits encoded in a SURID are set dynamically when the query executes. a query named quot;PRIVATE_ACCOUNT_ACCESSquot; might be parameterized with a username and password, and write FOR UPDATE into the ACCESS_CONTROL bits. a query named quot;PUBLIC_ACCOUNT_VIEWquot; would not be parameterized with username and password, but would NOT set the FOR UPDATE or FOR DELETE access control bits. Conclusion: SURID allows the query to specify the security model for results returned from the query.
    • What has characterized the architecture of database computing CLIENT/SERVER Irony: why can't the client be web based? Who says the client has to be a LAN client?
    • Let's look at some tools and live demos
    • Concluding remarks 1. What are today's options for cloud databases, and why can't they be easily accessed by pure JavaScript APIs? o today's cloud databases cannot be accessed from AJAX API's. 2. What are the gaps between the Web 1.0 database security model, and the unforgiving JavaScript environment? o The RDBMS security model cannot be applied to AJAX. 3. How can we create a new AJAX/RIA security paradigm for Database as a Service (DaaS)? o Introducing a paradigm shift in the security model, which is the goal of the NextDB.net project.