UT DALLAS Erik Jonsson School of Engineering Computer

UT DALLAS Erik Jonsson School of Engineering & Computer Science SECURED INFORMATION INTEGRATION WITH A SEMANTIC-WEB BASED FRAMEWORK FEARLESS engineering

What is a web service? • Everyone would agree with a general definition like this: “A Web service is a software system designed to support interoperable machine-to-machine interaction over a network. ” (Source: W 3 C) FEARLESS engineering

SOAP, WSDL and UDDI • Most people understand Web Services to be the “triumvirate” of SOAP, WSDL, and UDDI SOAP Envelope Platform B Platform A Payload Application A SOAP Client Security Token SSL Application Web B Service WSDL (Web Services Description Language) UDDI Web Services Directory FEARLESS engineering 3

SOAP-based web services Web services and SOAP are often considered the same FEARLESS engineering

REST • But, SOAP is not the only kind of Web Service communication • REST stands for REpresentational State Transfer • Described in a thesis by Roy Fielding (Day Software, co-founder of the Apache Software Foundation, co-author of HTTP and URI RFCs) • REST applies the architecture of the Web to Web Services - Each URI is a distinct resource, as in the browser-based Web - URIs be bookmarked and cached - Don’t reinvent the “wheel” • Used by Amazon, Google, Flickr, and many others FEARLESS engineering 4

REST • In REST, everything is a resource • “Resource Modelling” is required at the outset. Model each document, and each process, as a “resource” with a distinct URI • Then use the standard HTTP “verbs” to interact with the resource: • - GET: Retrieve a representation of a resource. Does not modify the server state. A GET must have no side effects on the server side • - POST: Create or update a representation of a resource • - PUT: Update a representation of a resource • - DELETE: Remove a representation of a resource FEARLESS engineering 5

Example of a REST Weather Service • GET /weatherforecast/02110 HTTP/1. 1 - Get the weather forecast for Boston • POST /weatherforecast HTTP/1. 1 - Upload a new weather forecast for San Jose by sending up an XML document which conforms to the appropriate Schema - Response is a “ 201 Created” and a new URI 201 Created Content-Location: /weatherforecast/95101 • PUT /weatherforecast/95101 HTTP/1. 1 - Update an existing resource representation • DELETE /weatherforecast/02110 HTTP/1. 1 - Delete the resource representation FEARLESS engineering 6

Contrast with SOAP Weather service • POST /weatherforecast. asmx HTTP/1. 1 - Send a SOAP message to get the weather in Boston • POST /weatherforecast. asmx HTTP/1. 1 - Send a different SOAP message to create a forecast for San Jose - Response is a custom SOAP response message • POST /weatherforecast. asmx HTTP/1. 1 -Send another SOAP message to update the San Jose weather forecast • POST /weatherforecast. asmx HTTP/1. 1 - Send another SOAP message to delete the Boston weather forecast • Notice anything? - Everything is a POST. All the details are in the SOAP messages FEARLESS engineering 7

Reinventing Protocols • In REST, HTTP is the protocol - Well known, simple, and established - Only four methods: GET, POST, PUT, DELETE - A network admin can look at something like “GET /weatherforecast/02110” and understand what it is doing - Requests can be bookmarked - Responses can be cached • By contrast, in SOAP, developers effectively create their own protocols - Everything is a POST - Rather than using “GET, POST, PUT, and DELETE”, the methods and operations are in the SOAP messages themselves - A network admin just sees POSTs and cannot understand the purpose of the traffic without looking into the SOAP messages themselves FEARLESS engineering 8

More differences between SOAP and REST 1. SOAP is transport neutral - SOAP can be used across FTP, SMTP, Message Queues - But REST is tied to HTTP only 2. SOAP includes a whole stack of “composable” WS-* specifications - WS-Security for inserting security tokens into SOAP headers, WSReliable. Messaging, WS-Transactions, etc etc - But since WS-* builds on top of SOAP, it does not apply to REST - Proponents of REST would argue “use HTTP infrastructure for reliable messaging and security. Don’t reinvent the wheel” - Experts argue that REST is “as safe as HTTP” FEARLESS engineering 9

REST in Practice • REST is seen as “more simple to develop than SOAP” because you can create a Query. String just by concatenating strings together • Most developers find it easier to concatenate strings together and then do a “GET” to a URI like Google’s “do. Google. Search”, rather than to create a SOAP request - SOAP products are getting easier to use though, the gap is closing… • This simplicity is the main reason for REST’s popularity FEARLESS engineering 10

REST’s popularity – a famous data point Source: Jeff Barr, Web Services Evangelist at Amazon. com FEARLESS engineering 11

When to use SOAP instead of REST • WS-Security defines how to encrypt just part of an XML message - e. g. to encrypt search strings into a search engine - Rather than reinventing the wheel, use SOAP for this • WS-* includes reliable messaging and transaction support • SOAP can be applied to FTP traffic and MQ, REST can’t - So, use SOAP for these applications • SOAP supports attachments, although there are three different specifications for how to do attachments right now (MIME, DIME, MTOM). - Nevertheless, use SOAP when you need to send around binary data or large attachments FEARLESS engineering 12

RESTful Interface in Blackbook • Blackbook is a semantic web-based framework which provides analysts an easy-to-use tool which federates queries across local and remote data sources to access valuable data Why REST in Blackbook? Semantic data is a collection of different vocabularies and REST allows visualizers to show semantic data in an easy manner as compared to SOAP. Implemented in following Blackbook modules: 1. workspace-workflow 2. workspace-workspace 3. workspace-blackbook FEARLESS engineering 13

Workflow • Workflow is used to build complex processing sequences by stringing together BLACKBOOK algorithms • A workflow process definition can be executed any number of times. • An individual execution of a process definition is called Process Instance. • Functionalities in RESTful Workflow: 1) GET the process definition 2) DELETE the process definition 3) PUT the process definition 4) POST the process definition 5) PUT the process instance 6) GET the process instance FEARLESS engineering 14

Workspace • Workspace subsystem is a general purpose storage system that uses a directory metaphor to organize content • Currently, the only items stored in the workspace are “workflow process definitions” and “process instances” ( In future, user preferences and assertions content may be stored in the workspace). • Functionalities in RESTful Workspace: 1) GET the root folder 2) PUT a subfolder under root folder or any other subfolder 3) GET the child items of a given folder 4) PUT a process definition under a given folder 5) GET the process definition for a given user 6) DELETE the item under a given folder FEARLESS engineering 15

Blackbook • Blackbook provides analysts an easy-to-use tool which federates queries across local and remote data sources to access valuable data • Analysts can make logical inferences across the data sources, add their own knowledge and share that knowledge with other analysts using the system • Functionalities in RESTful Blackbook: 1) GET the list of algorithms 2) GET the list of data sources 3) GET the list of local data sources 4) GET the field names of a particular data source 5) Search for a keyword in a particular data source (GET & POST) FEARLESS engineering 16

Technologies used • Java / J 2 EE • RESTEasy – A Jboss project that provides framework to help build RESTful Web Services and RESTful Java applications • How it works? All the calls to the RESTful Web Service are handled by the REST Servlet at the Web Tier, which in turn invokes the EJB methods at the Enterprise tier and returns the result in the form of RSS or ATOM feeds. FEARLESS engineering 17

UT DALLAS Erik Jonsson School of Engineering & Computer Science Integrating Blackbook with Amazon S 3 FEARLESS engineering

Amazon Simple Storage Service (S 3) • “Amazon S 3 is storage for the Internet. It is designed to make web-scale computing easier for developers. ” • Amazon S 3 provides a simple web services interface that can be used to store and retrieve any amount of data, at any time, from anywhere on the web. FEARLESS engineering

Benefits of Amazon S 3 • Storage price as low as 15 cents per GB per month • Can be invoked via both REST and SOAP web services • Facilitates data sharing at nominal cost FEARLESS engineering

Blackbook with S 3 • Many organizations are using the services like Amazon S 3 for data storage. A few important questions arise here – • Can we use S 3 to store the data sources used by Blackbook? • Is the data we store on S 3, secure? Is it accessible by any user outside our organization? • How do we restrict access to the files to the users within the organization? FEARLESS engineering

Our Approach • We can use Amazon S 3 to store the data sources used by Blackbook. • To keep our data secure, we propose to encrypt the data using AES (Advanced Encryption Standard) before uploading the data files on Amazon S 3. • To restrict access to the files to the users within the organization, we propose to implement the Role-based access control policies using XACML (e. Xtensible Access Control Markup Language). FEARLESS engineering

Our Approach (Contd) • For authentication – Lamport One Time Password Mechanism • For authorization – XACML (e. Xtensible Access Control Markup Language) FEARLESS engineering

Lamport One Time Password Scheme OTP in general, • • • Valid for a single session or transaction NOT vulnerable to replay attacks Requires additional technology to work due to human memory limitations Lamport OTP Client & Server components use a common sequencing algorithm Generate a sequence of passkey values Each successor is based on the value of predecessor FEARLESS engineering

Lamport One Time Password Scheme S 6 s 6 S 5 S 4 S 3 Client Component Server Component S 2 S 1 = seed, S 2 = F(S 1), S 3 = F(S 2), …. , S[n] = F(S[n-1]) FEARLESS engineering

Lamport One Time Password Scheme 18 15 12 9 Client Component 6 3 Seed = 3 F(n) = Add 3 to predecessor S 1 = 3, S 2 = 3+3, S 3 = 6+3, …. , S 6 = 15+3 FEARLESS engineering Server Component

XACML request <Request> <Subject. Category="urn: oasis: names: tc: xacml: 1. 0: subject-category: access-subject"> <Attribute. Id="urn: oasis: names: tc: xacml: 1. 0: subject-id" Data. Type="urn: oasis: names: tc: xacml: 1. 0: datatype: rfc 822 Name"> <Attribute. Value>testadmin@blackbook. jhuapl. edu</Attribute. Value> </Attribute> <Attribute. Id="group" Data. Type="http: //www. w 3. org/2001/XMLSchema#string"> <Attribute. Value>users</Attribute. Value> </Attribute> </Subject> <Resource> <Attribute. Id="urn: oasis: names: tc: xacml: 1. 0: resource-id" Data. Type="http: //www. w 3. org/2001/XMLSchema#any. URI"> <Attribute. Value>911 Data. Source_On. Amazons 3</Attribute. Value> </Attribute> </Resource> <Action> <Attribute. Id="urn: oasis: names: tc: xacml: 1. 0: action-id" Data. Type="http: //www. w 3. org/2001/XMLSchema#string"> <Attribute. Value>read</Attribute. Value> </Attribute> </Action> </Request> FEARLESS engineering

XACML Policy <Policy. Id="Amazon. Access. Policy" Rule. Combining. Alg. Id="urn: oasis: names: tc: xacml: 1. 0: rule-combining-algorithm: ordered-permitoverrides"> <Description>This policy file is used to authorize users with Amazon S 3 datasource</Description> <Target> <Subjects> <Subject. Match. Id="urn: oasis: names: tc: xacml: 1. 0: function: rfc 822 Name-match"> <Attribute. Value Data. Type="http: //www. w 3. org/2001/XMLSchema#string">testadmin@blackbook. jhuapl. edu</Attribute. Value> <Subject. Attribute. Designator Attribute. Id="urn: oasis: names: tc: xacml: 1. 0: subject-id" Data. Type="urn: oasis: names: tc: xacml: 1. 0: data-type: rfc 822 Name"/> </Subject. Match> </Subjects> <Resource> <Resource. Match. Id="urn: oasis: names: tc: xacml: 1. 0: function: any. URI-equal"> <Attribute. Value Data. Type="http: //www. w 3. org/2001/XMLSchema#any. URI">911 Data. Source_On. Amazons 3</Attribute. Value> <Resource. Attribute. Designator Attribute. Id="urn: oasis: names: tc: xacml: 1. 0: resource-id" Data. Type="http: //www. w 3. org/2001/XMLSchema#any. URI"/> </Resource. Match> </Resources> <Actions> <Any. Action/> </Actions> </Target> FEARLESS engineering

XACML Policy(Contd) <Rule. Id=“Amazon. Access. Rule" Effect=“Permit”> <Target> <Subjects> <Any. Subject/> </Subjects> <Resources> <Any. Resource/> </Resources> <Action> <Action. Match. Id="urn: oasis: names: tc: xacml: 1. 0: function: string-equal"> <Attribute. Value Data. Type="http: //www. w 3. org/2001/XMLSchema#string">read</Attribute. Value> <Action. Attribute. Designator Attribute. Id="urn: oasis: names: tc: xacml: 1. 0: action-id" Data. Type="http: //www. w 3. org/2001/XMLSchema#string"/> </Action. Match> </Actions> </Target> <Condition Function. Id="urn: oasis: names: tc: xacml: 1. 0: function: string-equal"> <Apply Function. Id="urn: oasis: names: tc: xacml: 1. 0: function: string-one-and-only"> <Subject. Attribute. Designator Attribute. Id="group" Data. Type="http: //www. w 3. org/2001/XMLSchema#string"/> </Apply> <Attribute. Value Data. Type="http: //www. w 3. org/2001/XMLSchema#string">users</Attribute. Value> </Condition> </Rule> </Policy> FEARLESS engineering

Client (Browser) 1. Search input System Overview Policy Server 1 9. Results 2 a. OTP Stack Value + credentials Key Server -1 Trusted Server-1 Server OTP Value Search Engine 3 a. Key 1 Client OTP Stack 2 b. OTP Stack Value + credentials Policy Server 2 Other Data Sources XOR 8. Decrypted data source 4. XORED Key Trusted Server-2 3 b. Key 2 Encryption / Decryption Service Provider Blackbook OTP – One Time Password FEARLESS engineering 7. Encrypted data source Amazon File Manager Key Server 2 5. AWS Credentials + data source name 6. Data source file (encrypted form) Server OTP Value Amazon S 3 Server

Steps 1. The user U fires a search query to Blackbook (Step 1 in figure). Blackbook federates the queries across various data sources along with data source F securely on Amazon S 3. 2. We follow the One Time Password (OTP) scheme to authenticate the client( Blackbook in this case) for using the AWS S 3 services. The client machine sends the topmost value on the OTP stack along with the user credentials and the request to the trusted server 1 & 2. (Steps 2 a and 2 b in figure) 3. If the value passed by the client matches with the value on the OTP stack on the trusted server and the policies applicable for the user are valid for the request , the trusted server sends the “key” used to decrypt the data source. (Step 3 a and 3 b in figure). 4. The keys key 1 and key 2 obtained from the trusted servers 1 & 2 are XORed to obtain the original key used to decrypt the data source F (Step 4 in figure) FEARLESS engineering

Steps (Contd) 5. Amazon File Manager passes the Amazon account credentials and the data source name to retrieve the data source. (Steps 5 and 6 in figure) 6. The Encryption / Decryption Service Manager retrieves the encrypted data sources and using the XOR-ed key , decrypts the data source. (Steps 7 & 8 in figure) 7. Blackbook performs search on the data source retrieved from Amazon along with other data sources and returns the results to the user. (Step 9 in figure) FEARLESS engineering

Advantages • No Single Point of Failure For the system to be hacked, the hacker needs to obtain control of both the Trusted Key servers • We don’t store the final keys used for encryption as we XOR the keys k 1 and k 2 to generate key k used in encryption FEARLESS engineering

Upload - statistics FEARLESS engineering

Download - statistics FEARLESS engineering

UT DALLAS Erik Jonsson School of Engineering & Computer Science Comments !! Questions !! Suggestions !! FEARLESS engineering

UT DALLAS Erik Jonsson School of Engineering & Computer Science Thank you !! FEARLESS engineering