Government of Newfoundland and Labrador
Office of the Chief Information Officer
Solution Delivery: Enterprise Architecture
High Sensitivity – Authorized Distribution Only
DETAILED ARCHITECTURE DESIGN (DAD)
Notes:
1. Sections A and B are to be completed by the project team and sent to SDEA@gov.nl.ca for review by the
Project Architecture Review Board (PARB).
2. Section C will be completed by the PARB upon approval of the DAD. Once approved, the DAD will be sent
back to the project team by SDEA.
Purpose - The purpose of the Detailed Architecture Design (DAD) document is to determine the technical
suitability of a project’s architectural design. It is NOT meant to determine support requirements or the need to
assign OCIO resources to the project (although it may be used as supporting documentation in those decision
making processes).
Project Name
Widget Payment System
Project Number
123
Project Manager
Widget PM
(name)
Application Delivery
Manager
Widget DM
(name)
Assigned Manager of
Operation – Server / Storage
Widget DM
(name)
Assigned Manager of
Operation – Network /
Security
Widget DM
Assigned Manager of
Operation - Service Delivery
Widget DM
(name)
(name)
Assigned Manager of
Application Services
Widget DM
(name)
Anticipated Implementation
Date
2009-10-01
Estimated Date for
Beginning of Execute Phase
2009-05-15
(e-mail)
widgetdm@gov.nl.ca
(e-mail)
widgetdm@gov.nl.ca
(e-mail)
widgetdm@gov.nl.ca
(e-mail)
widgetdm@gov.nl.ca
(e-mail)
widgetdm@gov.nl.ca
(e-mail)
709-555-1212
(phone number)
709-555-1212
(phone number)
709-555-1212
(phone number)
709-555-1212
(phone number)
709-555-1212
(phone number)
709-555-1212
(phone number)
Note: For the accurate date, check project status reports
Detailed Architecture Design (DAD) – Sample DAD
Template Version 2.5, 2010-08-001
widgetpm@gov.nl.ca
Page 1 of 27
High Sensitivity
Government of Newfoundland and Labrador
Office of the Chief Information Officer
Solution Delivery: Enterprise Architecture
Project Description
The Government of Newfoundland and Labrador has been selling widgets to
the public since 1997. This is an entirely manual process with orders being
taken over the phone, payments being accepted via credit card and cheque
and orders being mailed out. Due to demand from the customers, a web
solution has been authorized to offer widgets over the internet with online
payments using credit cards and debit cards. Financial Management has
dictated that all online payments will use the WTYM Broker, so this system
will integrate with the existing centralized OCIO WTYM Broker for online
payments. This Government of Newfoundland and Labrador system supports
payments via credit card or INTERAC over the internet and is certified for PCI
compliance.
Multi-Phased Deployment
Yes
No
The initial phase will provide the ability for online payment for widgets using
credit cards or debit cards using the existing WTYM Broker System.
A second phase will implement customer activity and administration reports,
e-mail notification of updates / upgrades to widgets, e-mail and fax
confirmation of shipping, payment using cheques and integration into the
Government of Newfoundland and Labrador website.
Information Classification
High
Medium
Low
Confidentiality
X
Integrity
X
Availability
X
Detailed Architecture Design (DAD) – Sample DAD
Template Version 2.5, 2010-08-001
Unclassified
PAGE 2 OF 27
HIGH SENSITIVITY
Government of Newfoundland and Labrador
Office of the Chief Information Officer
Solution Delivery: Enterprise Architecture
REVISION HISTORY
Version
1.0
Date
2009-10-02
Summary of Changes
Initial draft of DAD
Name
Widget Architect
This template is owned and maintained by the Enterprise Architecture (EA) Division within the Solution Delivery
Branch of the Office of the Chief Information Officer (OCIO). Direct questions about this template to
SDEA@gov.nl.ca
IMPORTANT NOTES FOR COMPLETING THIS DOCUMENT
Each section of the Detailed Architecture Design must be completed in full. If a particular section is not
applicable to this project, then you must write Not Applicable and provide a reason.
Important Note: No sections are to be deleted from this document.
Insert the TRIM document number into the footer. Project teams can obtain a document number from the ISC
(OCIOISC@gov.nl.ca).
Text contained within << >> provides information on how to complete that section and can be deleted once the
section has been completed.
Note: To insert a document (BRD, PPIA, PIA, et cetera):

From the Insert Menu, click object;

Click the Create from File Tab. Find the document via the Browse button;

Check the Display as icon checkbox;

Click OK; and

An object will be inserted directly into this word document.
Detailed Architecture Design (DAD) – Sample DAD
Template Version 2.5, 2010-08-001
PAGE 3 OF 27
HIGH SENSITIVITY
Government of Newfoundland and Labrador
Office of the Chief Information Officer
Solution Delivery: Enterprise Architecture
TABLE OF CONTENTS
DETAILED ARCHITECTURE DESIGN (DAD) ....................................................................................................... 1
REVISION HISTORY ................................................................................................................................................ 3
IMPORTANT NOTES FOR COMPLETING THIS DOCUMENT............................................................................................ 3
SECTION A ............................................................................................................................................................. 5
DESIGN AND TECHNOLOGY DETAILS ....................................................................................................................... 5
USER COMMUNITY ................................................................................................................................................. 5
APPLICATION ARCHITECTURE ................................................................................................................................. 6
Overview .......................................................................................................................................................... 6
DATABASE ARCHITECTURE ................................................................................................................................... 11
SECTION B ........................................................................................................................................................... 12
DESIGN AND TECHNOLOGY DETAILS ..................................................................................................................... 12
Standards ....................................................................................................................................................... 12
OVERVIEW ........................................................................................................................................................... 12
Description ..................................................................................................................................................... 12
SUPPORT REQUIREMENTS .................................................................................................................................... 12
SERVICE REQUIREMENTS ..................................................................................................................................... 13
ASSESSMENTS RESULTS ...................................................................................................................................... 13
SOLUTION STACK ................................................................................................................................................. 13
TECHNICAL ARCHITECTURE (INFRASTRUCTURE) .................................................................................................... 14
Infrastructure .................................................................................................................................................. 14
APPLICATION INTEGRATION................................................................................................................................... 19
DATABASE ARCHITECTURE ................................................................................................................................... 20
SECURITY MODEL ................................................................................................................................................ 20
Overview ........................................................................................................................................................ 20
Infrastructure Security .................................................................................................................................... 22
Application Security........................................................................................................................................ 25
Database Security .......................................................................................................................................... 26
ENTERPRISE STORAGE AND RECOVERY ................................................................................................................ 27
SECTION C .................................................................................................ERROR! BOOKMARK NOT DEFINED.
APPROVED BY ..................................................................................................... ERROR! BOOKMARK NOT DEFINED.
Detailed Architecture Design (DAD) – Sample DAD
Template Version 2.5, 2010-08-001
PAGE 4 OF 27
HIGH SENSITIVITY
Government of Newfoundland and Labrador
Office of the Chief Information Officer
Solution Delivery: Enterprise Architecture
SECTION A
Note – This section covers the Business Environment and the data maybe available from the Business
Requirement Document.
DESIGN AND TECHNOLOGY DETAILS
GIS Component
Is there a GIS Component?
Yes
No
Data Conversion
Is data conversion part of the project?
Yes
No
Customer information (name, address and contact information) and order
information will be extracted from the Order Tracking System and will be
verified prior to initial load of data into system. This is scheduled to occur on
Oct. 2, 2009 over the weekend prior to implementation on Oct. 4.
Data Cleansing
Is data cleansing part of the data conversion?
Yes
No
USER COMMUNITY
Description
There are 7 internal staff comprised of DBAs, help desk staff, administrators
and Financial Clerks who will require access to the widget system.
There are approximately 25 widget dealers who buy from the Government of
Newfoundland and Labrador and resell to the general public worldwide.
User
“Who”
Number of
Users
Distinct User
Groups
Connection
Internal
1
Solution Delivery
DBA
Intranet
Internal
1
Application Support
Help Desk
Intranet
Internal
3
Widget department
staff
Administrator
Intranet
Internal
2
Department of
Finance
Financial
Clerks
Intranet
External
1,000 +
25 widget dealers
25 widget
dealers who
buy for resale
Internet
N/A
N/A
~1,000 general public
This is based on
current number of
purchasers
Extranet Partners
N/A
Information
Public information is being displayed in the Widget Payment System, but
personal information such as credit card numbers are being processed in the
Detailed Architecture Design (DAD) – Sample DAD
Template Version 2.5, 2010-08-001
N/A
PAGE 5 OF 27
HIGH SENSITIVITY
Government of Newfoundland and Labrador
Office of the Chief Information Officer
Solution Delivery: Enterprise Architecture
WTYM Broker application but are not retained there.
Software Type
COTS Customization (NOT
Configurations)
COTS
SaaS
Custom
N/A
APPLICATION ARCHITECTURE
OVERVIEW
Appropriateness of Solution
Tools: JSP pages are extensively used within OCIO and so this technology
was chosen for the webpages because of its wide spread use.
Architecture: The solution is divided into presentation, logic and database
layers to support a physical three tier architecture as this is deemed to be
more appropriate for an external facing application of moderate sensitivity.
Description
The solution is divided into several layers:
1. Presentation Layer – consists of the web presentation layer including
the web Administration layer;
2. Logic Layer – consists of the business logic layer including the
administration logic layer; and
3. Database Layer – consists of the application database.
Layers
The Widget Payments system has two separate paths of execution for
administrative and non-administrative access both of which will be configured
in a three tier environment:
1. Administrative Path – This consists of the administrative web
presentation layer and the administrative business logic layer:
a. Web Presentation Layer - This layer includes the admin web
server and is where the admin pages will reside. Java Server
Pages (JSP) on an Apache web server will be used to create and
host the pages. Some initial data validations will be performed at
this layer.
b. Admin Logic Layer – All administration logic will be installed
here. This layer will include a Java application running on an
Apache Tomcat Application Server that will perform final data
validation and database calls.
2. Non-administrative Path – This consists of the non-administrative web
presentation layer and the non-administration business logic layer:
a. Web Presentation Layer - This layer will include the application
web server and is where the application pages will reside. Java
Server Pages (JSP) on an Apache web server will be used to
create and host the pages. Some initial data validations will be
performed at this layer.
b. Business Logic Layer - The Widget Payments application
Detailed Architecture Design (DAD) – Sample DAD
Template Version 2.5, 2010-08-001
PAGE 6 OF 27
HIGH SENSITIVITY
Government of Newfoundland and Labrador
Office of the Chief Information Officer
Solution Delivery: Enterprise Architecture
server will be installed in this layer. It is here where all
communications with the database are initiated. This layer will
include a JAVA application running on an Apache Tomcat
Application Server that will perform final data validation and
database calls. The WTYM Broker will be called to make
payments using credit / debit cards from this layer. No
administration logic exists in this layer.
3. Database Layer – The Widget Payment Database server will reside on
the database layer located on the Government of Newfoundland and
Labrador SAN. It will house all the transaction and customer information
for the application and will be called from both the Admin Logic Layer and
the Business Logic Layer.
Session Management
Data Flows
A security token is assigned to each session and this token is associated with
the customer’s account. This data will be stored in the database and used to
log each of the transactions as payments are made.
Activity
Data Flow
Create
customers
Customer name, address and contact information
transmitted to the application server. Application server
inserts this information into the database.
Create
orders
Order number returned from the application server that has
generated it in the database
Create
orders
Order number, widget number, quantity and customer
number transmitted to the application server and
subsequently logged in the database
Create
payments
Order confirmation is transmitted to the application server
that in turn calls the WTYM Broker via a web service call to
validate the credit card number. If the credit card is valid, the
user is sent a prompt to confirm the order. If the credit card
is invalid, the user is asked to correct the credit card
information and resubmit or cancel.
Create
payments
If the user confirms the order, the response is sent to the
application server that in turn sends the credit card number,
expiry date and charge amount to WTYM Broker to charge
the card. WTYM Broker returns the result to the application
server. If the payment was successful, the payment is
logged to the database and a success response is sent to
the presentation layer. If the payment was not successful,
an error response is sent to the presentation layer.
Retrieve
customer
The user selects profile update from the main menu and a
request is sent to the application server that retrieves the
customer information from the database and sends it back
to the presentation layer.
Detailed Architecture Design (DAD) – Sample DAD
Template Version 2.5, 2010-08-001
PAGE 7 OF 27
HIGH SENSITIVITY
Government of Newfoundland and Labrador
Office of the Chief Information Officer
Solution Delivery: Enterprise Architecture
Retrieve
customer
details
The user selects history list from the main menu and a
request is sent to the application server that retrieves all the
customer orders, order details and payment details from the
database and returns it to the presentation layer.
Retrieve
widgets
The user select Widgets List from the main menu and a
request is sent to the application server that retrieves a list
of available widgets from the database and returns it to the
presentation layer.
Update
customer
Customer information changes are sent to the application
layer from the presentation and then the application layer
updates the database with the changes.
Update
orders
Order information changes are sent to the application layer
from the presentation and then the application layer updates
the database with the changes.
Delete
customer
(customer
will not be
physically
deleted,
but will be
set to
inactive)
Customer number is sent to the application layer. The
application layer updates the database to set the customer
to inactive.
Create
widgets
Administrator requests the creation of a new widget. The
Widget information is sent to the application server and the
application server updates the database
Retrieve
widgets
Request is sent to the application server to retrieve a list of
widgets. The application server retrieves the list of widgets
from the database and sends the list to the presentation
layer.
Update
widgets
Administrator sends a request to the application server to
update a specific widget. The application server updates the
widget information in the database.
Delete
widgets
(only
widgets
with no
orders can
be deleted)
Administrator sends a request to delete a specific widget to
the application server. The application server retrieves the
count of the list of orders for this widget. If the count is zero,
the application server deletes the widget from the database
and sends a response back to the presentation layer. If the
count is not zero, the application server sends an error
response back to the presentation layer.
Reset
customer
The Administrator sends a request to the application server
to set the password of a specific account to a specific value.
Detailed Architecture Design (DAD) – Sample DAD
Template Version 2.5, 2010-08-001
PAGE 8 OF 27
HIGH SENSITIVITY
Government of Newfoundland and Labrador
Office of the Chief Information Officer
Solution Delivery: Enterprise Architecture
password
The application server updates the password value in the
database.
Create user
accounts
A request is sent to the application server to create a new
user account. The application retrieves the list of accounts
with the same user. If the list is not zero, and error response
is sent back to the presentation layer, otherwise a new user
account is created in the database and a success response
is sent back to the presentation layer.
Lines of Code
About 5,000
Primary Screens
About 18 (not including simple administrative screens, pop-ups windows or
reports)
Presentation, Business and
Data Logic
The presentation layer consists of JSP webpages installed on the web server.
There is no business logic in the presentation layer but all entry fields are
validated prior to submitting data to the application server.
The business logic consists of web services installed on the application
server. They contain all business logic and are totally separate and
independent of the presentation layer. All data submitted to the application
layer is validated before being used.
The database layer contains all the data for the application. No business logic
is executed in the database.
Detailed Architecture Design (DAD) – Sample DAD
Template Version 2.5, 2010-08-001
PAGE 9 OF 27
HIGH SENSITIVITY
Government of Newfoundland and Labrador
Office of the Chief Information Officer
Solution Delivery: Enterprise Architecture
Application Architecture Diagram
Component Details
Note - For briefness, only the Web Presentation Layer is depicted in component-level detail; In a real DAD,
each component should be documented in detail, so in this sample system, there should be 5 component
breakdowns like the following
The Web Presentation Layer
The first logical layer of the non-administrative path is the web
presentation layer. This layer is primarily responsible for the
rendering of system information into the generic web-browser
compatible HTML and PDF formats.
It is this layer – and this layer alone - with which the external
public user interacts, and so there are numerous security
features, provided in the inbound communications and preapplication security levels.
Figure 1 depicts the logical components of the web
presentation layer in order: processing starts at the top of the
diagram, and is handed to components further downwards on
the diagram, one layer at a time.
Inbound Communications Security Level
First in this layer, as traffic arrives off the network, a hostbased firewall is traversed. The host-based firewall has
identical rules to those defined on the network level, but
protects from attacks on the same network segment. Next, the
Snort™ intrusion prevention system sits behind the firewall,
running in ‘inline’ or intrusion prevention mode. Suspicious
packets are blocked from reaching the application layer.
Pre-application Security Level
The web server software (Apache) next applies its own logging
and then filters well-formed requests with access control lists.
Logs are also forwarded to the Application server.
Application Security Level
Next is the application security level, which first runs the
internal context-specific intrusion prevention routines.
Following a successful test, the session/cookie handling
engine performs user authentication on a per-request basis.
Authentication is performed by the application permissions
engine.
Web Presentation Layer
Inbound Communications
Security Level
Host-based Firewall
Host-based Intrusion Detection
Sensor
SSL/TLS
Library
Pre-Application Security Level
Webserver Access Control Lists
Webserver Access Logging & Forwarding
Application Security Level
Controller Servlet
Internal Intrusion Prevention Routines
Session/Cookie Handling Engine
(Authentication)
Application-Level
Permissions Engine
(Authorization)
Presentation Logic Level
Dynamic Content
Static
Content
XSLT Template
Processor
Static
Content
Repository
PDF
Library
Template
Repository
WorkerBeans
Outbound Communication Level
HTTPServletRequest (Calls EJBs)
Persistent Connection Pool
SSL/TLS Library
Having passed the above security components, a request is
Figure 1 – Logical components of the
further processed by the Controller Servlet which handles the
Web Presentation Layer (Nonrequest, building a response from static or dynamic content.
Administrative Path)
Static content is stored in a repository, whereas dynamic
content must be fetched from the communications level and then rendered into web-formats by either the XSL
transformation engine or the PDF Generation Library before returning to the requesting client. When the page
controller requires dynamic data, it interacts with WorkerBeans which fetch information from the application
Detailed Architecture Design (DAD) – Sample DAD
Template Version 2.5, 2010-08-001
PAGE 10 OF 27
HIGH SENSITIVITY
Government of Newfoundland and Labrador
Office of the Chief Information Officer
Solution Delivery: Enterprise Architecture
server (which publishes Enterprise Java Beans) via the outbound communication level.
Outbound Communications Level
Data in the application logic layer is accessed via standard java WorkerBean calls to Enterprise Java Beans on
the Application Tier. The communications between the WorkerBeans client on the web presentation layer and
the Enterprise Java Beans on the application logic layer are executed through a pool of persistent connections
protected by the SSL/TLS encryption library.
DATABASE ARCHITECTURE
Note: For Database Security considerations refer to the Security Model section of this document.
Size of Database
1 GB
Anticipated Growth
Double in 5 years, but could be more or less as the public purchase widgets.
Database Management
System
Oracle 10g
Detailed Architecture Design (DAD) – Sample DAD
Template Version 2.5, 2010-08-001
PAGE 11 OF 27
HIGH SENSITIVITY
Government of Newfoundland and Labrador
Office of the Chief Information Officer
Solution Delivery: Enterprise Architecture
SECTION B
DESIGN AND TECHNOLOGY DETAILS
STANDARDS
OCIO Standards
Does the project follow OCIO standards as outlined in the Enterprise
Architecture Guidelines & Best Practice Binder?
Yes
No
Deviation(s)
Oracle Unbreakable Linux is used on the Application server instead of the
OCIO standard, Linux 5.
Reason for Deviation(s)
The solution uses a third party Widget Manager Component that is supported
only on this version of Linux.
OVERVIEW
DESCRIPTION
Business Requirement
Document
There is no sample business requirements associated with this DAD.
Public Facing System
Will any component of this system be delivered via the Internet?
Yes
No
SUPPORT REQUIREMENTS
System Availability
Required
Standard Government Business Hours
24 x 7
Extended Government Business Hours
Although the system may be available 24 hours per day except for
maintenance windows, it is only required to be available during normal
business hours. All issues can be addressed the next business day if they
occur outside of normal business hours (e.g. issue occurs at 11pm on Friday,
can be addressed Monday morning)
Identify who supports:
OCIO
Vendor
Other
Application
-
DBMS
-
Infrastructure
-
Detailed Architecture Design (DAD) – Sample DAD
Template Version 2.5, 2010-08-001
PAGE 12 OF 27
HIGH SENSITIVITY
Government of Newfoundland and Labrador
Office of the Chief Information Officer
Solution Delivery: Enterprise Architecture
- << Identify who >>
Other: identify
SERVICE REQUIREMENTS
System Availability
The system is not designed to be highly available using clustered servers and
load balancers as the load is expected to be light and not stress the web
server.
ASSESSMENTS RESULTS
Is a Vulnerability
Assessment (VA) required?
Yes
No
Although the solution has a Low Sensitivity security classification, it does
collect credit card information and pass it to the MTYM Broker for processing.
IM Assessment
Low Sensitivity - Although the solution processes credit card information, it is
not stored in the database, but is passed through to the MTYM Broker for
processing.
Preliminary Privacy Impact
Assessment (PPIA)
Completed with no issues.
Privacy Impact Assessment
(PIA)
PIA Required?
Yes
No
SOLUTION STACK
Operating System
Database Tier – Linux 5
Application Tier – Oracle Unbreakable Linux
Web Tier – Linux 5
Web Server
Apache Web Server 2.2.11
Application Server /
Middleware
Apache Tomcat 6.0.18
Development Languages
Java Standard Edition 6 (1.6.13)
With Java Servlet 2.5 and JSP Specification 2.1
Java Server Pages 2.1
Java Servlet 2.5
Client Device
Internet Explorer 6+
Mozilla Firefox 3.0+
Detailed Architecture Design (DAD) – Sample DAD
Template Version 2.5, 2010-08-001
PAGE 13 OF 27
HIGH SENSITIVITY
Government of Newfoundland and Labrador
Office of the Chief Information Officer
Solution Delivery: Enterprise Architecture
TECHNICAL ARCHITECTURE (INFRASTRUCTURE)
INFRASTRUCTURE
Description
The proposed Widget Payment System will operate as a perimeter web
application, configured in a Public Access Zone, dependent on the WTYM
Broker for online payments. Since this solution has no requirement for
redundant web services for the user access, the enterprise load balancer is
not required at this time.
However, since the financial management system requires that all online
payments use the WTYM Broker for online payments, this system will
integrate with the existing enterprise load balanced e-payment solution.
(Further details on security are outlined on page 23 – Infrastructure Security).
The Web services will operate on VMware servers placed behind the
Governments External Firewalls, with Intrusion Detection and Prevention
enabled to ensure the availability, security and performance of e-services.
SSL acceleration is not required based on the anticipated concurrent users.
Connection settings like ‘Stickiness’ of sessions, are also not required at this
time.
No Network enhancements are required / anticipated at this time.
External facing Production Web Server

IBM HS21 Blade
o
3GB RAM
o
2 72GB internal SAS hard drives
o
1 dual core CPU

Redhat Enterprise Linux 5

Apache Web Server

Java Server Pages
External facing Production Application Server

o
3GB RAM
o
2 72GB internal SAS hard drives
o
1 dual core CPU

Oracle Unbreakable Linux

Apache Tomcat

Java Servlet

Widget Manager Component
Detailed Architecture Design (DAD) – Sample DAD
Template Version 2.5, 2010-08-001
IBM HS21 Blade
PAGE 14 OF 27
HIGH SENSITIVITY
Government of Newfoundland and Labrador
Office of the Chief Information Officer
Solution Delivery: Enterprise Architecture
Database Server

IBM HS21 Blade
o
8GB RAM
o
2 72GB internal SAS hard drives
o
2 dual core CPU
o
QLogic HBA add-on adapter for SAN connectivity

Redhat Enterprise Linux 5

Oracle Enterprise 10g Database
Internal facing Production Administration Web Server

VMWare Virtual Server
o
1GB RAM
o
20GB virtual hard drive
o
Single virtual CPU

Redhat Enterprise Linux 5

Apache Web Server

Java Server Pages
Internal facing Production Application Server

VMWare Virtual Server
o
1GB RAM
o
20GB virtual hard drive
o
Single virtual CPU

Oracle Unbreakable Linux

Apache Tomcat

Java Servlet

Widget Manager Component
Development Web Server

VMWare Virtual Server
o
1GB RAM
o
20GB virtual hard drive
o
Single virtual CPU

Redhat Enterprise Linux 5

Apache Web Server

Java Server Pages
Development Application Server

Detailed Architecture Design (DAD) – Sample DAD
Template Version 2.5, 2010-08-001
VMWare Virtual Server
PAGE 15 OF 27
HIGH SENSITIVITY
Government of Newfoundland and Labrador
Office of the Chief Information Officer
Solution Delivery: Enterprise Architecture
o
1GB RAM
o
20GB virtual hard drive
o
Single virtual CPU

Oracle Unbreakable Linux

Apache Tomcat

Java Servlet

Widget Manager Component
Development Database Server

VMWare Virtual Server
o
1GB RAM
o
20GB virtual hard drive
o
Single virtual CPU

Redhat Enterprise Linux 5

Oracle Enterprise 10g Database
See the diagrams below for a depiction of the network/security zones,
firewalls, ports and protocols et cetera.
Environment
Detail
Data
Production
The Administration Web Server and Production data.
the Administration Application Server
will both be virtualized using VMWare
as they will not be used frequently
and performance requirements are
minimal.
Development
All servers are virtualized in this
environment and the Administrative
and
Application
servers
are
combined. All patches are applied to
this environment as they become
available.
Test data only (no production data
will ever be replicated into this
environment).
Test
All servers are virtualized in this
environment and the Administrative
and Application servers are separate
to provide a more accurate test
environment.
All
updates
and
patches are tested here prior to being
applied in production.
Production widget data is replicated
into this environment, but customer,
order and payment data is not
replicated and is created by the
testers in the test environment.
Staging
N/A
N/A
Detailed Architecture Design (DAD) – Sample DAD
Template Version 2.5, 2010-08-001
PAGE 16 OF 27
HIGH SENSITIVITY
Government of Newfoundland and Labrador
Office of the Chief Information Officer
Solution Delivery: Enterprise Architecture
Training
N/A
N/A
Other: << identify >>
N/A
N/A
Technical Architecture Diagram
GNL Internal Network
Production Zone
(Internal facing only)
Controlled Operations Zone
(Internal facing only)
Internal Access Zone
(Internal facing only)
Web Browser
Admin GUI
Web Services
Via SOAP
Over SSL
SSL
Widget Payments
Admin Application Server
(VMWare)
Port
7777
HTTPS
Ports
Widget Payments
Admin Web Server 80 & 443
(VMWare)
Widget Payments
Administrator / Help Desk
SSL
Widget Payments
Database Server
Port
1521
Web Services
Widget Payments
User Application Server Via SOAP
Over SSL
Port
7777
Public Access Zone
(External facing)
Internet
Web Services
Via SOAP
Over SSL
Port
7777
Widget Payments
Database On SAN
HTTPS
Widget Payments Web
Server
WTYM Broker
Clustered Application
Server
Web Browser
Application GUI
Ports
80 & 443
WTYM Broker
Clustered Application
Server
Production User
Items with cross hatched background are items with which this
project interacts but are not being developed as part of this
project
Widget Payments System
Production Technical Architecture Environment
Figure 0-1 Production Technical Architecture Diagram
Detailed Architecture Design (DAD) – Sample DAD
Template Version 2.5, 2010-08-001
PAGE 17 OF 27
HIGH SENSITIVITY
Government of Newfoundland and Labrador
Office of the Chief Information Officer
Solution Delivery: Enterprise Architecture
GNL Internal Network
Production Zone
(Internal facing only)
Controlled Operations Zone
(Internal facing only)
Internal Access Zone
(Internal facing only)
SSL
Widget Payments
Admin Application Server
(VMWare)
Web Services
Via SOAP
Over SSL
Port
7777
Web Services
Via SOAP
Over SSL
HTTPS
Web Browser
Admin/Application GUI
Ports
Widget Payments
80 & 443
Web Server
(VMWare)
Port
1521
Widget Payments
Database Server
(VMWare)
Widget Payments
Developer/Tester
Port
7777
Widget Payments
Database On SAN
WTYM Broker
Application Server
(VMWare)
Items with cross hatched background are items with which this
project interacts but are not being developed as part of this
project
Widget Payments System
Non-Production Technical Architecture Environment
Figure 0-2 Non-Production Technical Architecture Diagram
DISASTER RECOVERY
Disaster Recover Plan
At this time, the DR plan for this solution is currently being assessed with a
requirement for the recovery of the E-payment and WTYM broker systems to
be available, should the primary internet accessible website experience a
service disruption.
E-services are important to Government and we will work with the DR team to
appropriately plan and test our functionality. A DR plan for this solution will
hinge on the redundancy and configuration of Government’s Internet and
application solution in general.
Validation
The Widget System DR plan will originally be validated through the OCIO DR
strategy once it is operational. Therafter, DR application testing will
commence as scheduled by the OCIO in accordance with the application
priority list.
TRAFFIC FLOW
Communication
Requirements
The production Environment of the Widget solution will interface with the
existing WTYM broker system to complete financial transactions.
Administration of the servers in the production environment will be infrequent
Detailed Architecture Design (DAD) – Sample DAD
Template Version 2.5, 2010-08-001
PAGE 18 OF 27
HIGH SENSITIVITY
Government of Newfoundland and Labrador
Office of the Chief Information Officer
Solution Delivery: Enterprise Architecture
with periodic updates to the server, Operating system and application.
Since the Widget payment system relies on the Controlled Operations Zone,
Intrusion detection and protection will be enabled between the Internal
Access Zone and the Controlled Operations Zone.
Port
Source
Destination
443 (SSL)
Internet Users
External Widget Payments Server
443 (SSL)
Government of Newfoundland and
Labrador Network users (Admin)
Admin web server
80 (HTTP)
Internet Users
Web Server (external)
1521
Admin Application Server
User Application Server
Database
7777
Admin Web Server
Admin Application Server
7777
Public Web Server
Widget Application Server
Network Traffic
The expected network traffic requirements bandwidth for the web servers are
considered minimal.
The bandwidth required for this solution is standard for web to application tier
communications. The application itself is designed to handle 1000+ users,
however, we anticipate the number of concurrent users to be higher towards
month end during payment periods. Using a Data Transfer Calculator the
estimated traffic per web user is approximately 20 (kbps -kilobits per second),
to the application layer. The traffic will be bursty and we do not anticipate
more than 100 concurrent users during peak periods of use. With the
exception of service updates to servers by Administrators, traffic patterns
should be nominal.
APPLICATION INTEGRATION
Description
The Widget Payment System makes WTYM Broker requests to the existing
WTYM Broker application to validate and charge credit and debit cards via a
web service provided by the WTYM Broker system. The data elements
passed to the WTYM Broker include the customer name, customer address,
credit/debit card number, charge amount and credit / debit card expiry date.
Two requests are made; the first request is to validate the card number and
the second is to charge the card. The second request could fail even if the
first request succeeded as there may have been a transaction from
elsewhere that decreased the available credit remaining below that required
for the current transaction.
WTYM Broker uses a plug-in provided by the Money Pool that provides an
API to interface with the Money Pool. The WTYM Broker validates the credit
card information and returns the valid/invalid result to the Widget Payment
System. If the credit/debit card is valid, then a charge transaction is sent to
Detailed Architecture Design (DAD) – Sample DAD
Template Version 2.5, 2010-08-001
PAGE 19 OF 27
HIGH SENSITIVITY
Government of Newfoundland and Labrador
Office of the Chief Information Officer
Solution Delivery: Enterprise Architecture
the Money Pool to confirm the charge to the card.
Confirmed charges are recorded in the Financial Portal system via an
interface from the WTYM Broker system to the Financial Portal. This is not
part of the Widget Payment system, but is an existing interface in the WTYM
Broker system. This is a scheduled job that runs periodically throughout the
day to keep the Financial Portal updated with the latest financial transactions
and transfers data using secure FTP.
Encryption
N/A
Required Availability
If the WTYM Broker is unavailable (request will timeout) and a response will
be sent to the presentation layer with a message that the payment service is
unavailable and to try again later or to call a phone number to place the order
manually.
DATABASE ARCHITECTURE
Note: For Database Security considerations refer to the Security Model section of this document.
Are Database Links used?
Yes
No
What type of Database Links
are used
Private
Public
Yes
No
Database Link Privileges
Are stored procedures used?
Global
N/A
N/A
20 – Used to control access to the tables and functionality to the users.
Is an Object-Relational
Mapping (ORM) layer used?
Yes
No
Does each table have a
primary key?
Yes
No
Are transactions used for all
database interaction?
Yes
No
Number of Database
Instances
Single instance
Database Normalization
Third Normal Form
SECURITY MODEL
OVERVIEW
User Controls (Identification
A user table in the database holds all accounts, passwords and roles for each
Detailed Architecture Design (DAD) – Sample DAD
Template Version 2.5, 2010-08-001
PAGE 20 OF 27
HIGH SENSITIVITY
Government of Newfoundland and Labrador
Office of the Chief Information Officer
Solution Delivery: Enterprise Architecture
and Authentication)
user with access to the database. The password hash (SHA-512) is stored in
the database. Each user of the system will have an entry in this user table.
Each customer completes a secure on-line registration process resulting in
the assignment of an account number. The account number is used as the
username; the customer must select a password that complies with password
complexity requirements which requires a minimum of 8 characters, both
upper and lower case as well as one digit or special character.
The customer account is stored in a user table and does not result in the
creation of a corresponding database account. The customer account does
not expire and the account passwords do not expire. The customer may
change their passwords at any time using a profile update page. They must
login to the application using this account and password which is
authenticated against the credentials stored in the Widget Payment database.
No Active Directory or any other kind of directory account is created for these
customers. This may change with the next phase as Government is in the
process of implementing an Identity Management Authentication and
Authorization system.
The system will be seeded with an administrative account and a helpdesk
account upon initial implementation. The administrative account may create
other administrative accounts or helpdesk accounts.
No user account whether administrative, helpdesk or customer will have an
account in the database. Four database accounts will be created
corresponding to the four defined roles. During login, the connection to the
database will use a special login account with role WPSLogin to connect to
the database and verify the user’s credentials. Each user will be assigned
one of the three predefined roles and the connection to the database will use
the appropriate account corresponding to the role assigned to the user once
the user has been successfully authenticated.
Roles
The following is a list of the Oracle roles and the activities to which each role
will be granted access:
Role
Activity
WPSUser
Create customers (user accounts);
Create orders;
Create payments;
Retrieve customer;
Retrieve customer details;
Retrieve widgets;
Update customer;
Update orders; and
Delete customer (customer will not be physically deleted,
but will be set to inactive).
Detailed Architecture Design (DAD) – Sample DAD
Template Version 2.5, 2010-08-001
PAGE 21 OF 27
HIGH SENSITIVITY
Government of Newfoundland and Labrador
Office of the Chief Information Officer
Solution Delivery: Enterprise Architecture
WPSAdmin
Create widgets;
Retrieve widgets;
Update widgets;
Delete widgets (only widgets with no orders can be
deleted);
Reset customer password; and
Create user accounts
WPSHelp
Reset customer password
WPSLogin
Retrieve user account details
Access Control List
Administrators are granted read-only access to infrastructure log files.
Data Segregation
All data resides in a single schema in the database with access to data based
on the user’s Oracle role.
Application Administrators can only create widgets, accounts and change
passwords.
Helpdesk users can only reset passwords.
Normal users can create accounts, orders, payments, retrieve / modify
customer details, update orders and delete their accounts (inactivates the
account).
Separation of Administrative
and User Traffic
Users may access the system only over the internet and administrators and
helpdesk users may access the system only over the Government of
Newfoundland and Labrador internal network using a specific administration
interface running on a separate server.
Shared Infrastructure
Will this project be deployed on shared infrastructure?
Yes
Data Integrity
No
All data entry is initially validated at the presentation layer and re-validated by
the application layer before being written to the database. Information
transiting between adjacent tiers (web server to application server;
application server to database server) uses SSL for encryption. Additionally,
the link between the application layer and the WTYM broker also uses SSL to
encrypt all communications.
INFRASTRUCTURE SECURITY
Description
Since this application will be accessed from outside the Government’s
internal network, the non-administrative web server is located in a Public
Access Zone (PAZ). A PAZ is a network inserted as a "neutral zone" between
an organization’s private network and the outside public network. It prevents
outside users from getting direct access to a server that has data. Users of
the public network outside the organization can access only the servers in the
Detailed Architecture Design (DAD) – Sample DAD
Template Version 2.5, 2010-08-001
PAGE 22 OF 27
HIGH SENSITIVITY
Government of Newfoundland and Labrador
Office of the Chief Information Officer
Solution Delivery: Enterprise Architecture
PAZ. The PAZ may typically also have the organization’s webpages so these
could be served to the outside world. However, the PAZ provides access to
no other internal data. In the event that an outside user penetrated the PAZ's
security, the webpages might be corrupted, but no other data would be
exposed.
The PAZ firewall allows access to the web server only via ports 80 and 443.
Access via port 80 is automatically redirected to port 443. Direct access to
the database servers is not permitted from the Internet.
The Internal Access Zone firewall allows access to the web server only via
port 443 and only from the internal Government of Newfoundland and
Labrador network.
The Controlled Operations Zone firewall allows access to the application
server only via port 7777. The Controlled Operations Zone firewall between
the Widget Payments application server and the WTYM Broker application
server allows access to the WTYM Broker application server only via port
7777 using SSL.
The Production Zone is not located on the same network segment as the web
layer. In addition, it is not directly accessible from the web layer. The
Production Zone allows access to the database server only via port 1521.
The Administration GUI will be installed on the internal Government network
and will not be accessible outside this network. No administrative functionality
will be accessible outside the Government network.
Firewall Rules
Access to the zones from various components and systems will be controlled
by the following Firewall Rules:
1. Web Server (both Admin and Application)
a. Web browsers via ports 80 and 443
b. McAfee Virus Scan
c. Redhat Update Proxy
d. TSM Backup
e. Nagios Monitoring
2. Widget Payments Application Server (both Admin and Application)
a. Web Server via port 7777
b. McAfee Virus Scan
c. Redhat Update Proxy
d. TSM Backup
e. Nagios Monitoring
3. WTYM Broker Application Server
a. Web Server via port 7777
b. Admin GUI via port 7777
c. McAfee Virus Scan
d. Redhat Update Proxy
e. TSM Backup
f. Nagios Monitoring
4. Database Server
a. Application Server via port 1521
b. McAfee Virus Scan
c. Redhat Update Proxy
d. TSM Backup
e. Nagios Monitoring
Detailed Architecture Design (DAD) – Sample DAD
Template Version 2.5, 2010-08-001
PAGE 23 OF 27
HIGH SENSITIVITY
Government of Newfoundland and Labrador
Office of the Chief Information Officer
Solution Delivery: Enterprise Architecture
The firewalls will reject access from any other components or system.
Inter-tier Encryption
All communications between tiers will use SSL.
Operating System Accounts
and Privileges
1. Root account to be locked down and not used for server administration
2. Individual administrator accounts are to be created and granted sudo
access for root actions.
3. There will be no individual user accounts created for access to the
Widget Payments servers.
Intrusion Detection
1. Network intrusion detection is provided by the in-house Government of
Newfoundland and Labrador solution.
2. Currently OSSEC is installed as our host intrusion detection system. This
program monitors system access and services and sends all log
information to a centralized support e-mail account that is monitored by
all Unix / Linux administrators currently working at the OCIO.
3. OSSEC also monitors file state information through SHA-2 checksums. If
a file’s checksum changes an alert is sent out to the support inbox
immediately.
Server Hardening
Servers will be hardened to the current Center for Internet Security (CIS)
standards.
Security Logs
All system event logs are stored locally and can be found in the /var/logs
directory. See syslog.conf output in error log information below. Read-only
access to logs will be available to administrators only.
Error Logs
All system error logs are sent to the central OCIO syslog server which is
monitored by the UNIX / Linux administration team.
Standard Redhat Linux /et cetera/syslog.conf file:
1. # Log all kernel messages to the console.
2. # Logging much else clutters up the screen.
3. #kern.*
/dev/console
4. # Log anything (except mail) of level information or higher.
5. # Don't log private authentication messages!
6. *.info;mail.none;authpriv.none;cron.none
/var/log/messages
7. # The authpriv file has restricted access.
8. authpriv.*
/var/log/secure
9. # Log all the mail messages in one place.
10. mail.*
/var/log/maillog
-
11. # Log cron stuff
12. cron.*
Detailed Architecture Design (DAD) – Sample DAD
Template Version 2.5, 2010-08-001
PAGE 24 OF 27
HIGH SENSITIVITY
Government of Newfoundland and Labrador
Office of the Chief Information Officer
Solution Delivery: Enterprise Architecture
/var/log/cron
13. # Everybody gets emergency messages
14. *.emerg
*
15. # Save news errors of level crit and higher in a special
file.
16. uucp,news.crit
/var/log/spooler
17. # Save boot messages also to boot.log
18. local7.*
/var/log/boot.log
19. kern.*;*.alert;*.err;*.notice;*.warn
@syslogserver
Security Patch Management
Critical patches will be tested and installed on the development servers as
soon as they are made available. Following successful testing they should be
installed on the production environment.
APPLICATION SECURITY
Description
Each customer is assigned an account number and specifies the initial
account password upon setup of a new account. The customer account does
not expire and the account passwords do not expire. The customer may
change their passwords at any time using a profile update page. There is no
database account created for these customers. They must login to the
application using this account and password which is authenticated against
the credentials stored in the Widget Payment database.
A security token is assigned to each session and this token is associated with
the customer’s account. This data will be stored in the database and used to
log each of the transactions as payments are made.
The administration GUI will be installed only on the internal Government
network and will be accessible only from there.
Input Validation
Each input field is validated in the presentation layer and again in the
application layer.
Account Management
User accounts can be created by the users themselves and they can update
their own passwords as well. These accounts are assigned the default role of
WPSUser.
Administrators can create other administrative accounts and helpdesk
account. They can reset passwords for all accounts. Administrative accounts
are assigned the WPSAdmin role. Helpdesk accounts are assigned the
WPSHelp role.
Helpdesk cannot create accounts but can change passwords for any account.
Password complexity rules are enforced: password complexity requirements,
which require a minimum of 8 characters, both upper and lower case as well
as one digit or special character. There are no password expiry or lockout
policies.
Detailed Architecture Design (DAD) – Sample DAD
Template Version 2.5, 2010-08-001
PAGE 25 OF 27
HIGH SENSITIVITY
Government of Newfoundland and Labrador
Office of the Chief Information Officer
Solution Delivery: Enterprise Architecture
Password changes are communicated via phone only.
Segregation of Data and
Privileges
There is no sensitive information stored in the database, however, roles are
used to determine what data can be accessed and updated.
Exception Management
The main entry point into the application will be wrapped in an exception
trapping block to prevent the possibility of an exception stack trace being
returned to the user.
All exceptions will be logged and any account with 5 login failures from the
same IP address within a 5 minute period will be blocked.
All error messages returned to the user will contain the minimum amount of
information required to convey the error.
Cached Data / Temporary
Files
No files are cached within the Widget Payments System.
Application Logging
The presentation layer logs logins, logouts, failed logins and any errors
encountered. The application layer again logs logins, logouts, failed logins
and all errors encountered in input received from the presentation layer,
communications with the database layer and communications with the WTYM
Broker.
Application Auditing
No auditing is required and no auditing is planned. The logs will be used in
the case of exceptional circumstances for troubleshooting purposes.
A file of confirmed charges is created by the WTYM Broker and transmitted to
the Financial Portal using SFTP. This file is deleted when SFTP successfully
transmits it to the Financial Portal. It may sit there for a while if the Financial
Portal is unavailable.
DATABASE SECURITY
Description
Roles have been implemented in the database and each user of the system
is assigned a database role.
Is Encryption required?
Yes
No
Encryption Keys?
N/A
Local User Management
N/A
Database Logging
Database log files are stored on the SAN in the same directory structure as
the database. Access has been restricted to the system administrators and
DBAs. Logged events include:

Logins and logouts

Creation of new accounts

Deactivation of existing accounts

Password changes / resets
Detailed Architecture Design (DAD) – Sample DAD
Template Version 2.5, 2010-08-001
PAGE 26 OF 27
HIGH SENSITIVITY
Government of Newfoundland and Labrador
Office of the Chief Information Officer
Solution Delivery: Enterprise Architecture

Placing orders

Deletion of orders

Payment confirmation/rejection from MTYM Broker
ENTERPRISE STORAGE AND RECOVERY
Note: The storage and recovery components will depend largely on the type of solution being developed.
Storage requirements are based on a best guess effort as to the capacity required to support the day-to-day
operations of the user community.
Storage Requirements
1GB
Description
Incremental back-ups are run on a nightly basis at staggered times on each
of the seven servers using TSM.
Encryption Type
Source
Detailed Architecture Design (DAD) – Sample DAD
Template Version 2.5, 2010-08-001
Target
Source and Target
PAGE 27 OF 27
HIGH SENSITIVITY