Online ID Checker. Version: Thundercat. Team 1

Transcription

1 Version: Thundercat Skyler Beckman, Dylan Fistrovic, Assel Gabdullina, Alex Jahns, Mikhail Kim, Calvin Sauer, Almas Talgambayev 1

2 Table of Contents Purpose Summary of Requirements User Requirements Client Requirements Web Server Requirements General Priorities Usability Performance Reliability Response Time Security Design Outline Design Issues Software Architecture Server Software Database Management System Cryptography: Key Generation Design Details Activity Diagrams User wishes to narrow search options User wishes to Login User wants to search a person s friends list User wants to compare the similarities between two people User want to make a basic search with no additional options UI Mockup 2

3 Purpose This document describes important aspects of the implementation of the ID Checker identity system. We will discuss priorities, issues, and important design details crucial to the project s success. Summary of Requirements User Requirements User can log in/out of an account User can create an account User can enter in a name and a birthday into the client application and click a submit button to search User can narrow the search with a city, a state, an address, a telephone number, usernames, etc. to aid web service in determining the identity User can limit the search to only include specific social networking sites User can compare two results for different people from between specific social networking sites User can compare two people overall differences User can rerun a previously saved search 3

4 General Priorities Usability The user interface must be intuitive to use for a new user, but still have enough utility that an experienced user can perform all the functions they require. Creating a basic search should be quick and easy allowing the user to skip picking more advanced options. After a search is finished the user should easily be able to start a new search on a friend of the person being searched with a simple click. Performance To make performance fast for the user a client server architecture is used. This allows the front end application to be simply connected to the server and not be slowed down by the user s computer. Java is used, since speed on the front end application does not need to be fast. Reliability System reliability is a design focus for the front end. The front end application for the user should not crash more than once out of hundred searches. The server itself should be up 99% of the time per two days. Response Time System response time should be no more than 9s after the last query from a social network. The user should also be able to track where the program is at while running. Such as if it is still querying a social network and which one, approximate time till the server is done checking for contradictions. Security The system being developed will be used to transfer sensitive data from the web server to the desktop application being used by the user. Even though this data is publicly available on the internet, this data will contain information about the users personal life. So we will be RSA for the key exchange between the server and client application, and AES will be used for the encrypting data being sent between the server and client. 4

5 Design Outline The system is composed of three subsystems, two of which we will be developing: the web service, the social networks, and the client. The diagram below shows the social networks (Facebook, Twitter, LinkedIn, Google+, Instagram) that the web service will interact with. All interaction with social networks goes through the web service. The client never sees this interaction. The web server also communicates with a database. The database stores user information (username and password) for logging into the application, and user saved searches for rerunning previous searches. User saved searches should not be confused with cached search results. The cache is stored locally on the client s machine. The client application sends a post request to the web service in an attempt to discern information about a given person. The web server will query each social network in turn using information supplied by the client, aggregate the information, and respond with a list a similarities. 5

6 Design Issues Implementation Languages Option 1.) Java Option 2.) C++ Option 3.) Python Option 4.) PHP Decision: The majority of the code will be written in Java, because the chosen server software,tomcat, requires it. Software Architecture Option 1.) Client Server Option 2.) Service Oriented Option 3.) N Tier Decision: There are two major components in our system. They are client and Web server. Therefore, after identifying the interfaces between them and based on principal requirements and use cases that we developed, we came to conclusion, that the best architectural pattern for our project is Client Server architectural pattern. Component diagram Front End Application Option 1.) Desktop application that lets the user connect to the server and perform searches. Option 2.) Web application that is accessed by users over a network and allows for searches. Decision: We decided to make front end application as desktop application that lets the user connect to the server to perform searches and allows for a better user experience. 6

7 Server Software Option 1.) Apache Tomcat Option 2.) JBoss AS Decision: Our group decision is Apache Tomcat. Because we have experience in working with Tomcat server software, so we do not have to spend a lot of time to learn about new software. In addition, JBoss does not have a servlet/jsp container and it uses Tomcat for that purpose. Database Management System Option 1.) MySQL Option 2.) Oracle Decision: Nowadays, MySQL is the most popular Open Source SQL database management system. It is very fast, reliable, scalable, and easy to use system. The MySQL is a client server system which consists of a multi threaded SQL server that supports different backends, several different client programs and libraries, administrative tools, and a wide range of application programming interfaces (APIs), which is perfectly suited for our project requirements. Data Acquisition Technique Option 1.) API Option 2.) Implementation of web scraping algorithm Decision: We can obtain user s data via open APIs : 1. Facebook s Api s (Facebook Application Platform) can be found at 2. MySpace Developer Platform (MySpace API s) can be found at 3. Twitter API s can be found at 4. LinkedIn API s can be found at 5. Google+ API s can be found at Google Developers API reference 6. Instagram API Console can be found at console/ 7

8 Cryptography: Encrypt Data vs. Unencrypted data Option 1.) Encrypt all data between web server and client application Option 2.) Send data all encrypted between web server and client application Decision: Encrypt all data sent between web server and client application. The reason this option was chosen was because the data being sent between server and client application contains information about people. RSA will be used the key exchange, and AES will be used for encrypting data sent between users and the web server. Cryptography: Key Generation Option 1.) Generate the symmetric key for the session every time user is authenticated. Option 2.) Use the same symmetric key for the user all the time. Decision: Generate a symmetric key for the session every time the user is authenticated. The reason this option was chosen was for the extra security in the case that the users key becomes compromised. 8

9 9

10 Design Details 10

11 The User directly interacts with the Client through the UserInterface. Events triggered by the UserInterface will make calls to Client methods, which in turn make requests to the Server. The Client's reference to the Server is instantiated at the start of the application. The Server is responsible for responding to requests from Clients. It is capable of forming HTTP responses, as well as making requests of its own to look up Profiles on social networks. To do this the Server consists of a list of APIWrappers. An APIWrapper is an interface that describes methods for pulling information from a generic social network. Concrete classes will implement this interface and provide implementations for specific social networks for grabbing user information (e.g. FacebookWrapper, TwitterWrapper, etc.). A Person is just a class containing textual data about a person. Name, date of birth, address, etc. A Profile is then just an aggregation of this information with a URL to a specific social profile. When the Client requests a list of similarities from the Server, the Server uses its ProfileAnalyzer to make comparisons between Profiles. It generates a Result object which contains a list of all the Profiles checked as well as an array of floats that quantify the degree of similarity between all fields. ProfileAnalyzer Specification The ProfileAnalyzer compares the data that is received from different social networking sites. The data is compared using non case sensitive string comparison. To determine the overall % matched certain search parameters are weighted differently according to importance. The first and last name is weighted 40%. The DOB is weighted for 40%, and the remaining search options are weighted for 20%. 11

12 Activity Diagrams User wishes to narrow search options The above figure shows the steps involved if a user wishes to narrow the search options. 12

13 User wishes to Login The above figure shows the steps involved if a user wishes to login. 13

14 User wants to search a person s friends list The above figure shows the steps involved if a user wishes to search a person s friend list. 14

15 User wants to compare the similarities between two people The above figure shows the steps involved if a user wishes to compare the similarities between two people. 15

16 User want to make a basic search with no additional options 16

17 UI Mockup Login Page 17

18 Dashboard/Home Screen 18

19 Search Results Page (Unpopulated) 19

20 Basic Search Page 20

21 Advanced Search Page (Not Fully Populated) 21

22 Correct Account Selection Page 22

23 Social Network Friends Page 23