Online Properties Auction System (OPAS) Domain

SOFTWARE ARCHITECTURE (WXGC6105)

Case Study

Online Properties Auction System (OPAS) Domain 12-Dec-2014

Authors:

Loay Aladib

Chang Hon Fey

Si Toh Chooi Ling

Yamani Nair Thamutharam

TABLE OF CONTENTS OPAS Domain Description ..................................................................................................................... 1 OPAS Domain Solutions ........................................................................................................................ 2 1.

Use Case Diagram....................................................................................................................... 2

2.

Quality Attribute ......................................................................................................................... 4 2.1 Availability ............................................................................................................................... 4 2.2 Security ..................................................................................................................................... 4

3.

Quality Attribute Scenario .......................................................................................................... 5 3.1 Availability Scenario................................................................................................................. 5 3.2 Security Scenario ...................................................................................................................... 7

4.

Tactics ........................................................................................................................................ 9 4.1 Tactics for Availability ............................................................................................................. 9 4.2 Tactics for Security ................................................................................................................. 11

5.

Architecture Pattern .................................................................................................................. 16

6.

Architecture Structure Category ............................................................................................... 18

7.

Justification ............................................................................................................................... 22

8.

Assumption ............................................................................................................................... 24

9.

8.1

Assumption I: .................................................................................................................... 24

8.2

Assumption II: .................................................................................................................. 24

8.3

Assumption III: ................................................................................................................. 24

Tools ......................................................................................................................................... 24

Appendix ............................................................................................................................................... 25 References ............................................................................................................................................. 25

OPAS Domain Description Designing the software architecture of the Online Properties Auction System (OPAS) is very crucial especially for supporting the services industry. This case study describes and justifies the proposed software architecture for the OPAS system which must include the following: 1. Main functionalities of the system (Use Case Diagram & Use Case Specifications). 2. Two quality attributes which are most important to the system and your justifications on why. 3. Two most representative concrete scenario for each of the quality attributes you specified in 2. 4. Explanation on how you apply relevant tactics to achieve the concrete scenario in 3. 5. Explanation on how you apply at least two relevant architecture patterns in your proposed software architecture. 6. The relevant Module, Component-&-Connector and Allocation structures documented using UML and/or other notations. Diagrams should be complemented with the corresponding textual descriptions. 7. Justifications on how your proposed software architecture meets the two quality attributes and the identified functionalities. 8. Any reasonable assumption that you have made. 9. Tools used.

1

OPAS Domain Solutions

1. Use Case Diagram

Figure 1: Use Case Diagram

The Online Properties Auction System (OPAS) is an online service which allows banker to expand their property auction on the internet. The public user may bid for the property which is available on the auction list. Both public user and banker have to register as the OPAS user in order to perform an activity with the system. Table 1 summarizes the description of the use case for OPAS system.

2

Use Case

Use Case Description

View Auction Property

To view the auction property and the relevant information.

Search Auction Property

To search auction property with the interested area.

Perform Bidding

To perform bidding on interested auction property.

Register

To register as a user of the OPAS system, either a banker or normal member.

Log-in

To log-in to the OPAS system with a registered username and password.

Manage Profile

To update the user profile detail such as contact information and log-in the credential.

To update the auction property detail such as bidding base Manage Auction Property bidding price, date and the period for bidding, bid increment Detail interval. Manage Payment

To perform deposit for bid and view activity history by property buyer.

View Auction Property To gain the summarized information on auction properties which are under the banker’s account. Status Summary View Bid Winner Profile

To view the bid winner profile and contact detail.

User Management

To reset the user log-in credential and status, send a notification, and extract user list with corresponding details.

System Management

To turn up/down the OPAS system for maintenance event, view audit trail log, system component status monitoring.

Table 1: Use Case Description

3

2.

Quality Attribute 2.1 Availability This bidding system is meant to be an on demand system, high availability which

allows flexible accessibility without any constraint of physical location and time. Thus, availability is concerned as one of the essential quality attributes which assure the system serve the purpose well. Apart from that, high availability will encourage a higher degree of user’s confidence and reliance on our system. Property buyers are confident of exposed to the latest news on auction property and comfortable to perform bidding without any anxiety on downtime. Meanwhile, for bankers, they are assured that their auction properties are always visible by public. 2.2 Security The security attribute was chosen as one of the most important quality attributes as well because in the OPAS, the property buyers’ personal data is highly confidential and the property buyers’ bidding will involve big amount of money, we must not allow the attackers/intruders to intrude the system or buyers’ personal and bidding information, yet we must provide access to legitimate users with authorized functionalities. Besides, buyers may deny their bids and blame that another party (such as their children or dog) has pressed the bid button which is not their own will to bid for the property. Therefore, we must make sure the system can provide the solutions to solve those security problems.

4

3. Quality Attribute Scenario 3.1 Availability Scenario 3.1.1 Scenario I: Normal Operation

Figure 2: Normal Operation

Description: Under a normal operation, the users are able to search an auction house by using the search module of the system. The user may provide the search detail and submit the search form for action. The search mechanism will be triggered and auction property which matches the search criteria will be returned in less than 3s.

5

3.1.2 Scenario II: Overloaded Operation

Figure 3: Overloaded Operation

Description: Property buyer who has registered to bid for the property will prompt with a message box saying “Please wait, currently, the server is busy” when they try to click on ‘Bid’ button to increase their bidding value under overloaded operation due to the OPAS server is not responding.

6

3.2 Security Scenario 3.2.1 Scenario I: Authentication

Figure 4: Authentication

Description: When the identified legitimate user try to change the sensitive data like username, password and user’s mobile phone number during normal operation environment, after the user changed the sensitive data and clicked submit, the system will send a TAC number to the user through SMS and prompt the user to double confirm his/her username and password plus asking the user to enter the TAC number of the SMS. If the confirmation data is incorrect, the system will not proceed with the change of the sensitive data.

7

3.2.2 Scenario II: Non-Repudiation

Figure 5: Non-Repudiation

Description: During the house auction opening period “which was set in the system by the house seller or banker”, when the properties buyer who has logged on to the system clicked the “Bid” button of the particular auction house which he/she has registered to bid for, the system will first prompt the properties buyer to confirm his/her decision whether he/she has determined to bid for the property “if no, then the process of bidding will not proceed”, if yes, then the system will request the properties buyer to enter his/her own password. If the password is correct, then only the system will save the record of bidding to the system database and the buyer’s action will be saved in the system audit trail. Therefore, properties buyer who has bided for the house cannot later deny having bided for the properties, and the system cannot deny having received the bids.

8

4.

Tactics 4.1 Tactics for Availability

Figure 6: Availability Tactics used in OPAS System

4.1.1 Fault Detection Tactics I: Ping/Echo by Status Check Module

Figure 7: Ping/Echo Tactic

9

There are application servers and databases in the OPAS system. In order to assure the components are at the available state for operation, ping/echo mechanism is applied to gain the status of the component. Ping/Echo is applied in the operation between OPAS server between OPAS database and operation between OPAS Database and OPAS Backup Database. If the targeted component doesn’t revert with echo after the ping from the source component, the fault can be detected then lead to action for recovery.

4.1.2 Fault Recovery - Preparation and Repair Tactic II: Active Redundancy by Status Check Module

Figure 8: Active Redundancy Tactic

In our proposed, we will introduce active and redundancy spare for OPAS server. The purpose is to receive and process identical inputs (Bid data) during live bidding process in parallel. This approach allows the redundant OPAS database server spares to maintain synchronous state with the active OPAS database server node. Moreover, this tactic will also make sure that if the active OPAS database server overloaded or down during the live house auction bidding, the redundancy OPAS database node server will take over immediately with updated bidding data in milliseconds duration. The described approach will be built in status check module.

10

4.2 Tactics for Security

Figure 9: Security Tactics used in OPAS System

4.2.1 Prevent/Resisting Attacks Tactic I: Authenticate actors by login authentication module The credibility of sensitive data in our online properties auction system to identify legitimate users, however, the objective of this sensitive data to protected from any an attacker. Thus, this kind of tactics security to identify who the users are by requiring the users to submit some sort of identification (method of authentication) to verify the users like: 

Login form (Username, Password)



Digital certificate (TAC number of SMS)

That to make ensure that the system is trying to find out who is purports to be.

11

Tactic II: Authorize actors by access role authorization module Once the system knows who is the legitimate user by login form and digital certificate (user must insert the correct TAC number of SMS) methods. The next important tactic security is authorization to determine if the users should have access to a given resource by checking the system to see if the users have privileges to perform a certain action. So the user has to rights to access and modifies his/her sensitive data to manage by providing some access control patterns within a system, by USER_ROLE or by USER_ROLE_IP like: 

ROLE_PROPERTY BUYER



ROLE_BANKER



ROLE_PROPERTY BUYER_IP



ROLE_BANKER_IP

Some of the methods for authorizations to decide if the users have permission to access a resource by assigning specific roles to each user, and then requiring different roles for different resources such as: 

Access Control for URLs

This kind of methods for any URL matching is secured to give the opportunity to legitimate users only as property buyer and banker that to prompt them to log to the system, otherwise, any URLs are not matching /ACCESS_ROLE/ are accessible by all users that mean the user in never prompted to log into the system.

12

EXAMPLE: for both authentication and authorization work for legitimate banker user as shown:

Figure 10: Authentication and Authorization Tactic

13

Target III: Limit Access by Web Application Firewalls Each request from unknown source may be a form of an attack so it is necessary to limit access by firewall to restrict the destination port/message source if it was not secured, at the same time it is not always possible to curb access based on the known source as in our online properties auction system such as (property buyer/banker) therefore, according to the Web Application Security Consortium (WASC), the Web Application Firewall is described as “intermediary device”, sitting between the Web Client (client-side component within the Java 2 Platform Enterprise Edition, “J2EE” is comprised of a client-tier) and the Web Server, so the WAFs is used to protect the web server from attack. Thus, some of the important features of the WAFs in our Online Property Auction system such as: 

Block attack masked by HTTPS encryption by inspecting SSL sessions using the web server’s private key as shown:

Figure 11: Limit Access Tactic



Detecting Policy Violations:

Restriction are permitted uses of network

protocols like Secure Shell (SSH) that is a cryptographic network protocol to secure the data communication, so one of the important ways to use SSH is to 14

use automatically generated public-private key pairs to simply encrypt a network connection and then, use password authentication to log on into the system by the legitimate users as property buyer and banker only. 

Resetting Offending Connections: also, the firewall has some of blocking rules so the web application of this system sometimes maybe have a “bad” connection for a short period time, depend on this problem the firewall will reset the packet and it will immediately send a reset to the web server.

4.2.2 Recovering From Attacks: Tactics IV: Maintain An Audit Trail by the trigger function of database store procedure Each transaction applied to the data in the system will be captured in the audit trail with its identifying information such as user’s IP address, login ID, date, and time. By having the audit information, actions of the attackers can be traced and system recovery can be made. Besides, it provides evidence about the requests made by the users so that non-repudiation can be supported “house buyer who has bided for the house cannot later deny having bided for the house, and the system cannot deny having received the bid”.

15

5. Architecture Pattern Normally, the architecture of a software system is very seldom limited to a single architectural pattern but is often a combination of architectural patterns that make up the complete system. Our Online Properties Auction System also is not the exception; we have adopted 3-Tier architectural deployment pattern and Client/Server architectural pattern in our software architecture, which has formed a 3-Tier Client/Server architectural pattern. By adopting Client/Server architectural pattern, multiple clients will be separated from the application server, where the client initiates one or more requests (using graphical UI through web browsers), waits for replies, and processes the replies on receipt. However, the server authorizes the client and then carries out the processing required to generate the result. The server will send responses using HTTPS to communicate information to the client. The main benefits of the Client/Server architectural pattern are higher security “data stored on the server and offer greater control of security than client machines”, centralized data access “data stored only on server, access and updates to the data are far easier to administer than in other architectural patterns” and ease of maintenance “ensure that client remains unaware and unaffected by a server repair, upgrade, or relocation”. However, the traditional 2-Tier client/server architectural pattern has some disadvantages, including the possibility for application data and business logic to be closely combined on the server, which may negatively impact system extensibility and scalability, and its dependence on a central server, which may negatively impact system reliability. To address these issues, we have combined the client-server architectural pattern with the 3-Tier (or N-Tier) architecture pattern and come out a 3-Tier client/server architectural pattern. By combining with the 3-Tier architectural pattern, the business layer of the system is deployed behind a web application firewall, which forces the deployment of the presentation layer on a separate tier in the perimeter network, while the data layer will be on another layer behind the business layer. The benefits of the N-tier/3-tier architectural pattern are maintainability “each tier is independent of the other tiers, updates or changes can be carried out without affecting the application as a whole” and availability “applications can exploit the modular architecture of enabling systems using easily scalable components, which increases availability”.

16

In order to avoid overloaded operations happened at the business layer during properties bidding or auction time, another application server and a load balancer will be added to assign tasks evenly between the two application servers. In addition, another backup of database server will be added to back up the data actively from the current database server to prevent any problem happens towards the current database server. Both of these actions are to increase the availability of the system.

17

6. Architecture Structure Category

Figure 12: Module Structure of OPAS System

18

The above diagram shows module structure of OPAS system. The entire relevant module involves in OPAS were grouped logically in order to divide development work to the development team later and also to store some source code under the same category package. Referring to the figure [13], all the related Object Relational Mapping [ORM] which responsible for mapping java object to OPAS relational database tables using XML configuration file were grouped under my.opas.orm package. Package my.opas.ejb contains few modules which consist of .java file for enterprise bean and controller class; where else all the JSP Page and dynamic HTML pages were group under my.opas.orm package. Below are the modules grouped under this my.opas.ejb package:

iteractiveCenter -



my.opas.ejb.userMngt -



Manage bidding properties

my.opas.ejb.payment -



Manage registration and login authentication module

my.opas.ejb.property -



Manage bidding module

my.opas.ejb.login -



Manage user

my.opas.ejb.bidding -



Send sms and email message

Manage payment

my.opas.ejb.systemMngt 

Manage component connection between database and OPAS web application server.



Manage OPAS Database active redundancy



Create Audit Trail



Turn on/off the OPAS server for maintenance purpose

19

Figure 13: Component-&-Connector and Allocation Structure of OPAS System 20

Component-&-Connector structure Client Server pattern is one of architecture patterns under Component-&-Connector which implemented in our proposed system. Referring to the above diagram our proposed system become server based application where the client terminates can only access or used our webbased application via a web browser. The Web browser will connect to load balance server which responsible to manage the client connection to both OPAS application servers. All the data received in the application server will be stored in database servers. A hot spare of the database server is connected to the database server in order to synchronize data in milliseconds.

Allocation structure The 3-tier pattern is used in our proposed system to separate the client tier, application tier, and database tier. The only web server which responsibility to expose the web URL in internet and client terminal is grouped in the client tier. Those application servers and load balancer server are grouped under application tier where the else database server is grouped in the database tier.

21

7. Justification The proposed software architecture online properties auction system has been designed to meet the following important quality attributes: 

Availability



Security

Accordingly these tactics to implement the said quality attributes has been taken into consideration as shown in diagram: Quality Attributes Availability

Tactics Fault Detection 1. Ping/Echo

Fault Recovery – Preparation and Repair

Module/Server my.opas.ejb.connec tionCheck.StatusChe ck

Ping/ echo mechanism

my.opas.ejb.connec tionCheck.StatusChe ck

Implement Active and redundancy spare for OPAS server

2. Active Redundancy

Security

Prevent / Resisting Attacks

Identified Functionalities

Synchronization of Active and redundant OPAS database server approach my.opas.ejb.login. Authentication

User Identification

my.opas.ejb.login.

Login form and

1. Authenticate Actors

2. Authorize Actors

Important Features 1. To assure the state of availability of the components for operation 2. Fault detection mechanism that leads to immediate recovery action 1. Eliminate single points of failure

2. High availability of redundant OPAS database spares server to take over the operation immediately 3. Avoid long system downtime period 1. Requiring user to submit comprehensive identification 2. Function to ensure that only recognized legitimate users are allowed to access the system 1. Authorization method to 22

Authorization

digital certificates

User access/role Identification method Access control for URLs 3. Limit Access

WAF

Limitation of Access by Firewall Session Encryption /Decryption using private key

Recovering from attacks 1. Maintain an Audit Trail

Trigger function of database stored procedures

Availability of audit trail to capture/log system users activity

determine user permission/rights, to perform a certain action 2. Validation of user eligibility to perform a certain action via TAC method 3. Limit URL accessibility to legitimate users only 1. Restriction of destination port message to an unknown source 2. Established secure session 1. Eliminate system vulnerability from attackers 2. Readily available necessary user activity information to implement easy traceability of possible system attacks and to implement immediate system recovery. 3. Non-repudiation supported

Table 2: Justification

23

8. Assumption

8.1 Assumption I: A stable network should be assured by the ISP. OPAS will not cover any faulty operation which is due to ISP network breakdown. 8.2 Assumption II: An OPAS user should only perform OPAS activity on browser IE8 and above, Mozilla, and Chrome which is supported by the local operating system.

8.3 Assumption III: No OPAS functions are open for an unauthorized user. One has to register and login to the system in order to use the OPAS function.

9. Tools Visual Paradigm Community Edition.

24

Appendix Abbreviation :

Description

EJB DB HTML HTTPS J2EE JSP OPAS ORM SSH SSL WAFs WASC XML

Enterprise Java Bean Database Hyper-Text Markup Language Hypertext Transfer Protocol Secure Java 2 Platform Enterprise Edition Java Servlet Pages Online Properties Auction System Object Relational Mapping Secure Shell Secure Socket Session Web Application Firewalls Web Application Security Consortium Extensible Markup Language

: : : : : : : : : : : : :

References [1] http://www.uml-diagrams.org/deployment-diagrams.html [2] http://www.visual-paradigm.com/features/uml-and-sysml-modeling/ [3] http://www.visualparadigm.com/support/documents/vpuserguide/94/2583/7192_creatingpack.ht ml [4] https://www.google.com/?gws_rd=ssl#q=software+architecture+books+pdf

25