Three-Tier Service Orientated System

secrettownpanamanianMobile - Wireless

Dec 10, 2013 (3 years and 4 months ago)

91 views

Three
-
T
ier

Service Orientated
System







Page
1


Three
-
T
ier Service Orientated System


Douglas McArthur




Submitted in partial fulfilment of

the requirements of
Edinburgh
Napier University

for the Degree

BEng

Computer Security and Forensics



School of Computing

August 2
010

Three
-
T
ier

Service Orientated
System







Page
2


Authorship Declaration

I,
D
ouglas McArthur,

confirm that this dissertation and the work presented in it are
my own achievement.

Where I have consulted the published work of others this is always clearly attri
b
uted;

Where I have quoted from the work of others the source is always giv
en. With the
exce
p
tion of such quotations this dissertation is entirely my own work;

I have acknowledged all main sources of help;

If my research follows on from previous work or is part of a larger collaborative r
e-
search project I have made clear exactly
what was done by others and what I have
contributed myself;

I have read and understand the penalties associated with Academic Misconduct.

I also confirm that I have obtained
informed consent

from all people I have i
n
volved
in the work in this dissertation
following the School's ethical guidelines


Signed:


Date:


Matriculation no:



PLEASE NOTE that in signing this page you are aware of the consequences of d
o-
ing this fraudulently as explained at

http://www.napier.ac.uk/ed/plagiarism/homepage.htm

Three
-
T
ier

Service Orientated
System







Page
3


Data Protection Declaration

Under the 1998 Data Protection Act, The University cannot disclose your grade to an
una
u
thorised person. However,
other students benefit from studying dissertations
that have their grades attached.


Please sign your name below
one
of the options below to state your preference.


The University may make this dissertation, with indicative grade, available to others.




T
he University may make this dissertation available to others, but the grade may not
be di
s
closed.



The University may not make this dissertation available to others.

Three
-
T
ier

Service Orientated
System







Page
4



Contents

1

INTRODUCTION

10

1.1

Project

Context

10

1.2

Aim and Objectives

10

1.3

Dissertation Structure

11

2

LITERATURE REVIEW

12

2.1

Introduction

12

2.2

NHS IT Strategies and Frameworks

12

2.2.1

NHS Information Management & Technology Strategy

12

2.2.2

The NHS Plan

13

2.2.3

The National Programme for IT

14

2.2.4

e
-
Government Interoperability Framework (e
-
GIF)

14

2.2.5

Health Level 7 (HL7)

15

2.3

Authentication and Authorisation

16

2.3.1

Acces
s Control

16

2.3.2

WS
-
Security

16

2.3.3

SAML (Security Assertion Markup Language)

17

2.3.4

OpenID

18

2.3.5

Kerberos

18

2.4

Conclusions

20

3

DESIGN & METHODOLOGY

22

3.1

Introduction

22

3.2

Software Architecture

22

3.3

Presentation Tier

23

3.3.1

Website Flow

23

3.3.2

Authentication Selection Logic

23

3.3.3

Control Flow

24

3.3.4

Authorisation Control Flow

25

3.3.5

Session Termination Logic

26

3.3.6

Web Interface for Authentication Selection

26

3.3.7

Default Screen Design

27

3.3.8

Restricted Resource Screen Desig
n

28

3.3.9

Access Denied Screen Design

29

3.3.10

Membership Database Schema

29

3.4

Logic Tier

29

3.4.1

Services

29

3.5

Data Tier

30

3.5.1

Patient Simulation Data Table Schema

30

3.6

Conclusion

31

4

IMPLEMENTATION

32

4.1

Introduction

32

4.2

Presentation Tier

32

4.2.1

Prototype Web.Config

32

4.2.2

Web Interface for Authentication Selection

32

4.2.3

Default Screen

33

4.2.4

Restricted Resource Screen

33

4.2.5

Access Denied

34

4.3

Logic Tier

34

4.3.1

Service Contract Realisation

34

4.
3.2

Service Realisation

35

Three
-
T
ier

Service Orientated
System







Page
5


4.4

Data Tier

37

4.4.1

Database PatientSimData Table Schema

37

4.5

Conclusions

37

5

EVALUATION

38

5.1

Introduction

38

5.2

Stress Evaluation

38

5.2.1

Preliminary Testing

39

5.2.2

Fail
-
Stop Evaluation

41

5.3

Conclusio
n

44

6

CONCLUSIONS

45

6.1

Introduction

45

6.2

Meeting the Objectives

45

6.2.1

Produce a review of previous NHS Information Technology st
rategies and frameworks
that together provide an understanding of the problems faced by modern IT infrastructures

45

6.2.2

Produce a review of relevant technologies that could potentially fulfil the requirements
outlined in th
e previous review

45

6.2.3

Design a mock service centric three
-
tier prototype that implements secure message
transmission and has the option of Federated Identity Management

45

6.2.4

Develop the p
rototype from the methodology and design specifications and then perform
an evaluation of the prototype through stress testing

45

6.3

Critical Analysis

45

6.4

Self
-
Reflection

46

6.5

Future Work

49

7

REFERENCES

51

8

APPENDIX

54

8.1

Service Contract Code Extracts

54

8.1.1

IHeartRateService

54

8.1.2

HeartRateArrayMessage

54

8.1.3

HeartRateMessage

55

8.1.4

HeartRate

55

8.2

Web.Config

56




Three
-
T
ier

Service Orientated
System







Page
6


Figures

Figure 3.3.1.1
-

Website Flow Design

23

Figure 3.3.2.1
-

Authentication Selection Logic

24

Figure 3.3.3.1
-

Authentication Control Logic

25

Figure 3.3.4.1
-

Authorisation Control Logic

26

Figure 3.4.6.0.1
-

Authentication Selection Design

27

Figure 3.4.6.0.2
-

OpenID Authentication Screen Design

27

Figure 3.3.7.1
-

Default Screen Des
ign

28

Figure 3.3.8.1
-

Restricted Resource Screen Design

28

Figure 3.3.9.1
-

Access Denied Screen Design

29

Figure 3.5.1.1
-

Patient Simulated Data Database Schema

31

Figure 4.2.2.1
-

Web Interface for Authentication Selection Screenshot

32

Figure 4.2.3.1
-

Default Screen Screenshot

33

Figure 4.2.4.1
-

Restricted Resource Screen Screenshot

33

Figure 4.2.5.1
-

Access Denied Screen Screenshot

34

Figure 4.3.1.1
-

Service Contract Class Realisation

35

Figure 4.3.2.1


Service Class Realisation

36

Figure 5.2.2.1
-

Data tier further fail
-
stop results

43


Three
-
T
ier

Service Orientated
System







Page
7


Tables

Table 5.2.1.1
-

Stopwatch results 100
-

1000 records

39

Table 5.2.1.2
-

Stopwatch results 100


1000 records without data render

40

Table 5.2.1.3
-

Stopwatch results 100


1000 records with data render

41

Table 5.2.2.1
-

Fail
-
Stop evaluation results

42

Table 5.2.2.2
-

Data tier further fail
-
stop results

43


Three
-
T
ier

Service Orientated
System







Page
8


Acknowledgements

I would like thank
William Buchanan (Bill) and Robert Ludwiniak for their support,
words of encouragement and advice during the course of th
e project
. Even during
periods of
concern,

neither party faltered and always made time to meet and discuss
the project.

I would also like to acknowledge all the lecturers I have had the pleasure to meet

during

my University career to date who provided
me

with the foundations required
to u
n
dertake this project.

Last but certainly not
least,

I would like to thank my parents who have
provided both
moral and financial support throughout
and prior to
my University career to date.

Three
-
T
ier

Service Orientated
System







Page
9


Abstract

The security of both
users and sensitive information is currently of concern to both
NHS professionals and the UK government. There is a
strong
requirement that i
n-
formation be nationalised and resources be made sh
arable over large distributed
network
s

whilst simultaneously ma
intaining secure procedures.

The sharing of such
sensitive information over such a wide are amongst a great number of people i
n-
creases the security risks to be overcome and he problem of interoperability must
also be considered.

This is further complicat
ed by the desire to make information
freely available and user centric.


This project aims

review a number of NHS IT strategies and frameworks to ascertain
the
requirements that the NHS are attempting to achieve, then review some suitable
technologies tha
t when implemented correctly can fulfil these requirements.

This i
n-
formation is then be utilised in design and subsequently development of a prot
o
type
implements secure technologies such as WS
-
Security for secure message transmi
s-
sion over unsecure network
s and OpenID for Federated Identity Management putting
the user in control of their own authentication.

The design was realised in the form
o
f a three
-
tier

Service Orientated system utili
s
ing the Microsoft.NET framework

as
this provided a number of benefi
cial helper classes such as MembershipProvider
and RoleProvider which are utilised in the a
u
thentication and authorisation of users
within a system. Microsoft.NET also provides methods for service contracts with d
e-
fine the form any messages sent between a

service and a consumer should take.

This is followed by an evaluation of the implemented prototyped is performed which
highlights the r
e
quirement for further testing due to erratic stress testing results.

Finally a conclusion on the report discusses the
effectiveness of the project at mee
t-
ing the outlined requirements, a critical analysis of the project, self reflection and
ends with suggestions of future work.

Three
-
T
ier

Service Orientated
System







Page
10


1

Introduction

1.1

Project Context

S
ecurity

is should be treated as a core concept in the development

of any IT solution
and can

ultimately

be

paramount to the

success or failure

of the solution
.

Maintai
n-
ing the confidentiality and integrity of data
is of high priority

in any organisa
tion or

business.
As an increasing number of organisations migrate tow
ards or expand
business
-
to
-
business commerce including a requirement for persistent connectivity
,

the
requirement

for trust relationships between security realms increases (Microsoft
Corp, 2004).
Trust and trust relationships
are an important concept of l
ivelihood that
is

based

predominately upon the identity of another party
. As individuals, we fr
e-
quently develop trust relationships between other objects (
Homo

sapiens or othe
r-
wise) whether we are aware of this relationship or
not
. The Oxford English
Dic
tionary Online (OED) d
e
fines trust as:

Trust [noun]


Firm belief in the reliability, truth or ability of someone or something

(Oxford English Dictionary
, 2010
)

Considering the level of regard placed upon trust in the physical world, it seems e
x-
traordinary

that such little emphasis is placed upon trust in th
e digital world. The
abi
l
ity for users to move between applications and ultimately between security
realms

is becoming increasingly attractive.

Authorisation is a concept of security that is often overl
ooked due as it is often ha
n-
dled synonymously with authentication. Authorisation fulfils two of the three prope
r-
ties of the security CIA concept, confidentiality and integrity (Buchanan, 2009).

A
well
-
devised

appropriate access control framework can redu
ce the amount of mai
n-
tenance required when managing users within a security realm

along with data co
n-
fidentiality and integrity.

1.2

Aim and Objectives

This
thesis

aims to
produce and evaluate and prototype service orientated

To
achieve these aims the follow
ing criteria should be
a
c
complished
:



Produce a review of previous NHS Information Technology

strategies and
frameworks that together provide an understanding of the problems faced by
modern IT infrastructures

Three
-
T
ier

Service Orientated
System







Page
11




P
roduce a review of relevant technologies

that
could potentially fulfil the r
e-
quirements outlined in the previous review



Des
ign a
mock service centric three
-
tier

prototype
that implements secure
message transmission and has the option of Federated Identity Ma
n
agement



Develop the prototype from the meth
odology and design specifications and
then pe
r
form an evaluation of the prototype through stress testing

1.3

Dissertation

Structure

This
thesis is structured in the following fashion:

Chapter

1


Introduction:

Discusses the topic of the project and provides a

brief
overview of its requirement. The aims and objects of the project are also provided in
this
chapter
.

Chapter

2


Literature Review:

Information regarding the IT strategies and fram
e-
works developed within the health sector is initially reviewed. Th
is is followed by an
examination of methods for the authentication and authorisation of users into and
from within a trust realm and possible delivery methods. Finally a conclusion is di
s-
cussed which provides the core information for the following Methodo
logy.

Chapter

3


Methodology:

Considering the information obtained from the conclusion
of the Literature Review, this
chapter

will provide documentation regarding the met
h-
ods to be utilised in the Implementation of the prototype.

Chapter

4


Implementati
on:

This
chapter

documents the development of the prot
o-
type based on the concepts outlined in the Methodology. Code extracts and scree
n-
shots will be provided to aid
documentation where required.

Chapter

5


Evaluation:

An evaluation of the prototype is
documented in this
cha
p-
ter
. A number of tests are performed regarding the rate at which the prototype ex
e-
cutes data re
trieval.
It

ends with an analysis of the results.

Chapter

6


Conclusion:

A critical evaluation of the overall project and the succes
s-
f
ulness of achieving the original aims an objectives.
A

self
-
analysis

is performed
which reviews the effectiveness at which the project was managed

and how any
challenges were overcome and
closes with a discussion of suggestions for possible
f
u
ture improvem
ent of the prototype.

Three
-
T
ier

Service Orientated
System







Page
12


2

L
iterature
R
eview

2.1


Introduction

This
chapter

begins with a review
of

historical

IT strategies and frameworks

impl
e-
mented by the UK National Health Service (NHS).
It describes issues the strategies
and technologies are to overcome fo
llowed by how they intend
to
achieve a resol
u-
tion.

Later
chapter
s of this chapter discuss a number of currently available technol
o-
gies
that could potentially satisfy the aims and objectives outlined in the introduction.

This
chapter

concludes with an ove
rview of the discussed IT strategies, fram
e
works,
protocols and technologies before leading into reasoning for selecting the chosen
strategies and technologies for the project.

2.2

NHS
IT Strateg
ies and Frameworks

2.2.1

NHS Information Management & Technology Strate
gy

The NHS endured radical reform during the early 1990s with the separation of ge
n-
eral health responsibilities being
delegated to local authorities. This increased the
r
e
quirement for contracting information between these authorities and their differing
locations, in order to communicate information regarding patients.

In 1992 the NHS Management Executive released a white paper „The Health of the
Nation


A Strategy for Health in England‟ which launched the Information Manag
e-
ment & Technology Strategy (IM
&T) to
:



ensure that information and information technology are managed as the signif
i-
cant resources they are, and that they are managed for the benefit of individual
patient care as well as for the population as a whole
”.

(NHS IM&T, 1992)

The IM&T descr
ibed five key principles core to the development of information ma
n-
agement and technology in the NHS:



Person centric information



Integrated systems



Information derived from operational systems



Secure and confidential



Network shared resources

Three
-
T
ier

Service Orientated
System







Page
13


The NHS Execut
ive developed four initiatives to support the implementation of the
five key principles:



National facilitating projects



Develop an IM&T infrastructure



Maximising value for money



Enabling people

In 1998 the NHS Executive released an updated IM&T strategy, I
nformation for
Health


An Information Strategy for the Modern NHS, which built upon the found
a-
tions placed by its predecessor. The repeating theme of this updated strategy was
:



Better care for patients, and improved health for everyone depend
s

on the a
vai
l-
ability of good information, accessible when and where it is needed
”.

(NHS IM&T, 1998)

The new IM&T strategy further refined a number of the key principles descr
ibed in
the 1992 IM&T strategy.

Included within this refinement are:



Electronic Health Reco
rds (national)



Electronic Patient Records (local)



National Electronic Library for Health (NELH)



Preserving patient confidentiality through Caldicott
report
recommendations

of
1997

2.2.2

The NHS Plan

In July 2000 the Department of Health (DH)
presented a white pa
per called “The
NHS Plan”. The NHS Plan was a comprehensive document which heavily criticised
current NHS strategies saying that “
The NHS is too much a product of the era in
which it was born
” (NHS P
lan, 2000
). The Plan did however also document a nu
m-
ber

of enhancements to existing IT strategies:



Electronic outpatient appointment booking by 2005



Access to electronic personal medical records by 2004



Electronic prescribing of medicines by 2004



All GP practices to be connected to NHSnet by 2002



Electronic pa
tient referral

Three
-
T
ier

Service Orientated
System







Page
14




Electronic test appointment creation

2.2.3

The National Programme for IT

The National Programme for IT stipulates that as a consequence of the number of
incompatible IT systems in use by the NHS, any patient records that have been m
i-
grated from pa
per records to digital records are still difficult to share.

The
aim of this initiative is to therefore introduce

an integrated NHS Care Records
service and split patient data into two elements; a local detailed clinical record for
use within local healthc
are communities, and summarised national summary clinical
record. This would allow the rapid transfer of patient information between hospitals
and GPs and individual GP clinics. The programme also reiterated on a number of
objectives outlined by the prev
ious IM&T and NHS Plan strategies such as „Choose
and Book‟ and the „Electronic Prescription Service‟.

The NHS Care Records service will comprise of two elements; a National Data Spine
(The Spine) and local NHS systems. The spine will be maintained by the

NHS IT
authorities whilst the local NHS system maintenance will be contracted out to private
organisations.

One issue identified by doctors and other professionals concerning the National Pr
o-
gramme for IT, is the protection of patients‟ confidentiality

(N
PfIT, 2007)
. The D
e-
partment of Health has however specified that the security to be implemented on this
IT infrastructure will be more secure than that of the Chip & Pin system currently uti
l-
ised by credit and debit card providers in the UK.

2.2.4

e
-
Government
Interoperability Framework (e
-
GIF)

In 2001 the government published the e
-
Government Interoperability Framework (e
-
GIF) which aims to “
enable the seamless flow of information across government and
public service organisations


(e
-
GIF, 2005)

using

open stan
dards, inte
r
operability,
coherence and scalability.

To achieve these aims the e
-
GIF specification describes eight key business policies,
some of which include:



Alignment with the Internet


make use of commonly utilised specifications
on the Internet



Adopt
ion of XML


utilise XML as the primary method for data manag
e-
ment



Adoption of the web browser as a key interface


all public sector IT sy
s-
tems are to be accessible via a web browser interface



Mandatory


all public sector services to implement e
-
GIF

Three
-
T
ier

Service Orientated
System







Page
15


The
e
-
GIF specifications, policies and their accompaniments are applicable to any
and all government systems that require the facilities to exchange information. The
e
-
GIF business policies are motivated by technical policies which document how the
business p
olicies should be implemented. For example the e
-
GIF interconnection
technical policy specifies that communications between internal government organ
i-
sations should utilise the Government Secure Intranet (GSI). External communic
a-
tion should utilise Secur
e/Multipurpose Internet Mail Extensions (S/MIME) using at
minimum 128bit TLS/SSL connections. Also when Web Services are implemented,
they should be based on the Simple Object Access Protocol (SOAP) and Web Se
r-
vice Definition Language (WSDL) specification
s

(e
-
Gif, 2005)
.

2.2.5

Health Level 7 (HL7)

Health Level 7 (HL7), founded in 1987, is international community accredited by the
American National Standards Institute (ANSI)
that

develops and promotes sta
n
dards
amongst healthcare organisations to increase workflo
w productivity

(HL7, 2007)
.
Health Level 7 collaborate with other standards organisations such as ANSI and the
International Standards Organisation (ISO) to develop protocols specifically for
communic
a
tion between the application layer of the Open Systems

Interconnection
(OSI) model (layer 7; ergo the name HL7).

Considering the number of different computer system utilised by health organisations
(Patient Administration Systems (PAS), EHR etc), the requirement for an interope
r-
able communications channel to
transfer information, either internal or external, is
high. HL7 develop a number of protocols for standardising data transfer, of which
their HL7 messaging protocol is the most widely utilised. HL7 messaging v2.x was
originally released in 1987 and provi
ded a text based (non
-
XML), delimiter based
backward compatible messaging protocol. The current version (v3.x) was released
in 2005 and utilises Object Orientated design principles and the Hierarchical Data
Format (HDF)

(OASIS, 2004)

along with XML as the

primary format for data transfer.

HL7 v3.x incorporates a number of development methods to aid the continued pr
o-
gression of HL7. The Reference Information Model (RIM) is an object model and
„the cornerstone of the HL7 Version 3 development process‟ provi
ding a „pictorial
representation of the HL7 clinical data (domains) and identified the lifecycle that a
message or group of related messages will carry‟. HL7 v3.x also saw the inclusion
of the HL7 HDF development framework for storage and management of la
rge data
sets and HL7 Clinical Document Architecture (CDA)

(HL7, 1999)

which specifies the
e
n
coding, structure and semantics of data HL3 v3.x transmissions.

Three
-
T
ier

Service Orientated
System







Page
16


2.3

Authentication and Authorisation

2.3.1

Access Control

Access control is an important security concept app
licable to both the physical and
digital worlds that enables authorities to control access to areas and resources. Dig
i-
tal access control encapsulates three key elements:



Authentication



Authorisation



Accounting

Authentication is the process of validating
a subjects identity, for which there are
numerous methods, for example; a user ID (and password), a digital certificate, iris
scan, fingerprint scan etc. Authenticators are commonly based on one or more of
the following criteria. Something you; know, hav
e or are.

Authorisation is the process of granting of access to services and applying permi
s-
sions to a subject for a service.

Accounting is the process of generating logs, or audit trails that detail transactions
performed by subjects upon a system and i
ts entities. Auditing performs two val
u-
able roles: security violation detection and consequently evidence should it be r
e-
quired.

Access control can be deployed using a number of methods, aside from
determining whether a user has the required privileges t
o a resource it can also be
used to co
n
strain the time and method for which the resource can be accessed.

Most multi
-
user Operating Systems perform access control in combination with a
u-
thentication.

2.3.2

WS
-
Security

Microsoft
provides a collection of security

related specifications collectively known as
Web Services Security (WS
-
Security) which it defines as
:



a comprehensive Web service security model that supports, integrates, and un
i-
fies several popular security models, mechanisms, and technologies (includ
ing
both symmetric and public key technologies) in a way that enables a variety of
systems to securely interoperate in a platform
-

and language
-
neutral manner



(
Microsoft
, 2007)


The collection contains a number
of specifications that can be implemented
within a
web service to enhance the security provided. Of pa
rticular interest are

the

WS
-
Trust and

WS
-
Federation specification
s

that define mechanisms for the

management
Three
-
T
ier

Service Orientated
System







Page
17


of security tokens and trust realms
,

and

federated management of identities, attri
b-
ut
es, authentication and a
u
thorisation between trusted realms.

Both the WS
-
Trust and WS
-
Federation specifications build upon the foundations
provided by the WS
-
Security specification that provides the core functionality for a
s-
suring message confidentiality,
integrity and
authenticity (IBM Corporation, 2007).

WS
-
Trust defines a process for
the transferral of identity claims, of a cl
ient within the
same trust realm,
as specified by the web service. If an invalid claim is supplied then
the web service can r
e
jec
t the request

(IBM Corporation, 2005).

WS
-
Federation
in
contrast aims to provide a model for sharing identifiers and attri
b
utes betwee
n trust
realms (IBM Corporation, 200
7
).

Although the
Microsoft

WS
-
Security collection co
n-
tains a number of highly advant
a
geous specification
s for Web Service security, the
specifications provided are still in their infancy and could therefore be seen as insu
f-
ficiently tested in a production env
i
ronment.

2.3.3

SAML

(Security Assertion

Markup Language)


Security assertions are one
basic building block of standards relating to the security
of SOAP messages
” (Bertino, Martino, Paci,
Squicci
arini,
2009)
. The Security A
s-
se
r
tion Markup Language is a

platform independent

framework for facilitating the e
x-
change of security information (as
sertions) about a pri
nciples identity for a given
domain.

SAML currently supports a number of user scenarios: Single Sign
-
On
(web), Attribute
-
Based authorisation and securing

web services
.
These user scena
r-
ios are
achieved

through the

transmission of mes
sages in an Extensible Markup
Language (XM
L) format
that

can
be transmitted either via Simple Object Access Pr
o-
tocol (SOAP), or via HTTP

message bindings

(OASIS Open, 2005)
.

To facilitate in
the exchange of security information, SAML makes use of the foll
owing concepts

(
IBM Corporation
,

2009
)
:



Assertions



The core of a SAML message of which contains one or more
statements made by an asserting party regarding the authentication, attribute
and ent
i
tlement decisions for a principle



Bindings


Specifies a low
er level transport protocol for SAML r
e-
quest/response communication such as SOAP or HTTP



Profiles


Allows the definition of combinations of assertions, protocols and
bindings that can be utilised in application specific use cases.

Due to the level utilise
d for the transmission of SAML messages the protocol is
prone to Denial of Service (DoS) attacks, this can however be averted by lowering
the level at which transmissions are made or restricting the number of parties a
l-
lowed to issue SAML requests. It is
also assumed that neither end
-
points of a SAML
Three
-
T
ier

Service Orientated
System







Page
18


communication are compromised, as this would render the protocol ineffective

(Be
r-
tino, Martino, Paci,
Squicci
arini,
2009)
.

2.3.4

OpenID

OpenID
is a
n Internet
orientated

decentralised user
-
centric
identity management

fram
e
work
. It provides a method of authentication that enables a user to verify their
ide
n
tity to a web service, known as a Relying
-
Party, without the RP requiring access
to Perso
n
ally Identifiable Information (PII).

Users provide a RP with an
identifie
r that

can
be either

a unique URL or
a digital t
o
ken.
The RP can then perform some logic
on the
user‟s

OpenID I
dentifier to ascertain their
OpenID
P
rovider

(OP)

and

subs
e-
quently

perform the authentication process

(
Reed
, Chasen, Tan 2
008
).

A major benefit
to the OpenID
protocol is

the user
-
centric nature
. This enables a
user to actively control
his or her

own PII
by
allowing or denying a RP access to r
e-
quested information during the authentication process.
It also allows a user to
„choose
-
and
-
move‟ betwee
n RPs and OPs due to the user having control of their
OpenID Identifier (Reed, Chasen, Tan 2008).

OpenID uses the current Internet
standards HTTP/1.1, Extensible Resource Identifier (XRI) and Extensible Resource
Discovery Service (XRDS), this means that a
ll user
-
agents and similarly all web
servers should support the protocol.
A number of security risks have

however

been
high
light

specifically relating to

OpenID SSO and its implementation of symmetric
key encryption which is known to be susceptible
to a n
umber of attacks such as
plaintext
-
attacks and cryptanalysis.

Another issue lies in the TTL of
the authent
i-
cated
session, the OpenID protocol does not specify a TTL and is therefore left to
the discretion of the RP (Hyun
-
Kyung Oh' &

Seung
-
Hun Jin
, 2008)
.

2.3.5

Kerberos

Massachusetts Institute

for Technology (MIT)

originally developed Kerberos

in the
1980s, as part of project
Athena
,
to provide


reliable authentication over open and
insecure networks where communications between hosts belonging to it may be i
n-
ter
cepted
” (
Ricciardi
,F
, 2007)
.

It

utilises strong
symmetric (private
-
key)
cryptogr
a-
phy
,

based on the trusted third
-
party Needham
-
Schroeder protocol
,

to authenticate
the identity of both a client and a server (mutual authentication).

Successful authe
n-
tic
a
ti
on enables a


process (client) running on behalf of a user (principle) to prove its
identity to a verifier (applicatio
n server
)


(Neuman, C & Ts‟o, T, 1994)
.
The Kerberos
protocol also provide
s

Single Sign
-
On functionality if desired allowing users to be
a
u-
thenticated for a number of services without the requirement to verify their identity
each time a new

service
is
requested.

The

basic Kerberos infrastructure must consist of three hardware d
e
vices:

Three
-
T
ier

Service Orientated
System







Page
19




Client workstation



Key Distribution Centre (Authenticati
on Server / Ticket Granting Server)



Service Provider

(Verifier)

Key Distribution Centres are assigned administrative domains (realms) for which
they are responsible for verifying the identity of any principle or service within its
boundaries. Authenticati
on between a principle and a service is not limited by realm
however assuming there is a trust relationship between the realms.

Whenever a
principle

wishes to utilise a SP they must first contact the AS which will
attempt to verify their identity. Upon
ve
rifying the principles identity
, the AS will pr
o-
vide the
principle

with a TGT
that

is subsequently passed to the TGS

as proof of
identity

along with the principle of the desired service. The TGS then determines if
the requested
service

e
x
ists and if so pr
ovides the
principle

with a ST

for use when
requesting a service from the SP.

Each ST is valid for only one SP, therefore the
process must be repeated to obtain a new S
T for a different SP. T
he initial stage of
authenticating with the AS can
however
be d
isregarded assuming the

TTL of the
TGT has not expired (Single Sign
-
On).

Kerberos is currently developed as part of the “MIT Kerberos Consortium” agre
e-
ment with support (financial and development) from a number of large organisations.
This large community

ensures that development becomes neither stagnant nor tu
n-
nelled towards a partic
u
lar outcome.

The Kerberos protocol provides strong mutual
authentication protecting against device spoofing. Encrypted communication b
e-
tween
a client and a KDC

preserves p
rinciples confidentiality whilst the KDC replay
cache decreases the probability of a replay attack.

The use of realms also means
the pr
o
tocol should scale well if the requirement arises.

Kerberos does however have limitations. Although the KDC
and SPs ut
ilise a 2
-
minute replay cache to store recently received requests, it is not impossible to pe
r-
form a replay attack however does require significant effort

(Kasslin, K
&

Ti
k
kanen,
A,
2003)
. The protocol is also particularly weak against password
guessing,

should
a legitimate principle use a weak password

it could potentially be broken via a di
c-
tionary attack. If

a client, SP or the KDC is

directly compromised the whole protocol
is rendered useless.

Implementing Kerberos also requires that services and appl
ications that wish to uti
l-
ise any services be modified to accept the Kerberos protocol. Although this may not
be an issue for custom in
-
house systems, it could potentially be an issue when using
pre
-
made software packages.

Three
-
T
ier

Service Orientated
System







Page
20


2.4

Conclusions

This
chapter

began b
y discussing a number of NHS IT strategies and

frameworks
that together provided
an understanding of the obstacles and concerns regarding
modern IT infrastructures.

The NHS Information Management & Technology strategy
highlighted a number of
fundamentals c
oncepts. It repeatedly talks about preserving the security and conf
i-
dentiality of data
, also

referring to the Caldicott report (NHS IM&T, 1998) and
spec
i-
f
y
ing that patient services can be improved through the “
availability of good
information
” (NHS IM&T,
1998). Good information is not just reliant upon its source
but
a
lso is validity that
can also be described as its

data

integrity. Integrity is a core
principle of the security CIA conc
ept (Confidentiality, Integrity

and Availability
)

for
which a truly s
ecure system will attempt, as no system is 100% secure, to preserve
all three pri
n
ciples.

Another reoccurring theme is the concept of networked resources, such as the Ele
c-
tronic Patient Records, Electronic Health Records

and access to personal medical
reco
rds. Making such information available over
a network solidifies the requirement
for a complex security model, not only that but also the requirement for interoperabi
l-
ity between heterogeneous systems.

A final point to be had in particular from these stra
tegies is the concept of patient
centric information. The NHS IM&T specified identifies and stipulates this as a r
e-
quirement (NHS IM&T, 1992) and although neither the 2000 NHS Plan or the NPfIT
specifically mention this, the aims they outline are distinct
ly orientated towards p
a-
tient centricity. Once again, this solidifies the requirement for comprehensive sec
u-
rity measures to preserve confidentiality, integrity and availability.

Two particular interoperability frameworks
currently in continued developed
were r
e-
viewed. Both reiterated the requirement for interoperability through the utilisation of
standards such as XML as a primary method for data management (e
-
GIF, 2005).
That said the HL7 implementation also provided a couple of custom data manag
e-
ment
protocols, which although are now
ANSI approved standards (OASIS, 2004)
are specifically orientated towards healthcare. This could potentially limit any sca
l-
ability of the system while reducing the availability of the framework outside of
healthcare. The

e
-
GIF framework however makes no custom message formats and
instead opts to uti
l
ise current open standards such as XML, SOAP and WSDL.

Chapter

2.3 discussed a selection of security orientated technologies, each of which
was focused on the confidentiality
and integrity properties of the CIA concept. A
brief
chapter

on access control was given that identified authentication, authorisation
and account as the three properties to be achieved for successful access control.

Three
-
T
ier

Service Orientated
System







Page
21


The following sub
chapter
s discussed f
our technologies that were specifically aimed
at access control however utilised different techniques to achieve the same goal.
Both SAML and WS
-
Security provide XML based message communication via
SOAP, HTTP or TCP and both support Single Sign
-
On
(IBM Co
rporation, 2009)
(Federated Identity Management)
. Microsoft had initially been partially developing
the SAML specification however halted to produce its own security framework known
collectively as WS
-
*. Where SAML is combined into a single specification
, WS
-
*
provides a collection of independently selectable and customisable.

Finally, two methods for Federated Identity Management were reviewed. Whilst
Kerberos is
an old
-
school competitor, OpenID is relatively new
however

applies the
same principles
for
the


reliable authentication over open and insecure networks
where communications between hosts belonging to it may be intercepted
” (
Ricc
i-
ardi
,F, 2007) Kerberos provides but in a more Internet effective manner.

A partic
u-
larly interesting idea to OpenID is

the ability to chose your own Identity provider
(Reed, Chasen, Tan 2008) allowing the user to move if they feel unsecure with their
current provider. Although identity providers authenticate in a standard method, the
methods utilise for storing a user‟s
personal data differs as an example, some Ide
n-
tity providers encrypt
all
user data whilst others do not.

In contrast, Kerberos utilises
a single pre
-
defined Identity provider, it was also developed to be used in conjun
c-
tion with the LINUX Operating System

and although is available in Windows format
is particularly complex to configure (even when integrated as part of Windows Active
Directory).

In conclusion from the research performed, it can be determined that there is a
strong requirement and desire for
user centric comprehensive security within ne
t-
work shared resources (NHS IM&T, 1992) and that from the authentication and a
u-
thorisation technologies reviewed, WS
-
Security and OpenID are most suited to fulfil
these requirements for this project.

Three
-
T
ier

Service Orientated
System







Page
22


3

Design &
Me
thodology

3.1

Introduction

The previous chapter concluded

that to overcome the problems faced by a modern
IT i
n
frastructure that the system should provide secure access to resources in a user
centric format.

This chapter provides a high
-
level overview of the
functionality

and
flow the prototype should implement in order to fulfil the requirements mentioned
above. It is segmented into four sub
chapter
s that individually describe, discuss and
provide fi
g
ures, where applicable, for the proposed software architec
ture and three
individual application tiers.

This chapter finishes with a conclusion that provides re
a-
soning and justification for the choices made during th
is Design & Methodology
chapter
.

3.2

Software Architecture

The Microsoft C# programming language and M
icrosoft .NET
framework

should be
the driving force behind the prototype
, as Microsoft Windows is the most
prevalent

operating system within the NHS
.
The .NET framework is
also
platform indepen
d-
ent thanks to the Common Language Infrastructure

(Microsoft,

2010)

(CLI, formally
known as Microsoft Intermediate Language MSIL) and specifically the Common I
n-
termediate Language (CIL) and Common Language Runtime components (CLR). In
2003,

the Intern
a
tional Organisation for Standardisation

(ISO) granted Microsoft,

HP
and Intel approval for their standardisation of the CLI
. This therefore meant

that any
programming lan
guage could

potentially interface with the CLI

assumi
ng it co
n-
formed to the standard
s requirements, allowing platform dependant languages to
become p
la
t
form independent and communicate with one another.

Another benefit
of the .NET platform is the individual components of which it is comprised: Windows
Communication Foundation (WCF), Windows Presentation Foundation (WPF), Wi
n-
dows Workflow Foundation (W
WF) and Cardspace (although only the former is to be
implemented as part of this prototype).

Novell currently develop an open source i
m-
plementation of the .NET fram
e
work
and CLI (Mono

Project
, 2010).

A reason for choosing C# as the programming language al
ternatively to another
.NET compliant language, such as VB.NET,
was its level of support within the pr
o-
gramming community.

Windows Server was used as Mono only supports up to .NET 2.5 however WCF was
not implemented until .NET 3.5

Three
-
T
ier

Service Orientated
System







Page
23


3.3

Presentation Tier

The pre
sentation tier is to be
realised

in the form of a web
interface
, the reason for
this being that a requirement of the prototype is that it should be accessible to as
many people as possible
,

on as many devices as possible.

In this modern environment, person
al and corporate, users commonly hav
e access
to an array of Internet enabled devices

with a web browser installed
.

All
current
common
web browsers

(Opera, Mozilla FireFox, Apple Safari
, Google Chrome etc)

are HTTP/1.1 standard compliant

(or should be)

and

therefore
be capable of rende
r-
ing the inte
r
face.

3.3.1

Website Flow

For security purposes the website should follow a particular flow, components
(green) are to be placed between the navigation (blue) which are to test for particular
attributes of the user navi
gating around the site. The restricted resources (violet)
should only be accessible after navigating through the flow of the site and the attri
b-
ute determining components have been satisfied.

This is depicted in figure 3.3.1.1
below.


Figure
3.3.1
.
1

-

Website Flow Design

3.3.2

Authentication

Selection

Logic

When a client requests the login page on behalf of a user

or the client is
r
e
directed
away from the requested page due to user authentication or authorisation

reasons
,
the login page should be r
e
ndered on the client.

Upon
the

login page
successfully

being

rendered, the

user should be presented with
two
authentication
options:



Option 1:
Standard login form which obtains a username and password



Option 2: OpenID

login
option which redirects to an OpenID login form that
obtains an OpenID identifier

If the user is part of an OpenID trust
authority,

they can elect to utilise the OpenID
a
u
then
tication

method
. This method will require the user input their unique Open
ID
identifier (URL) that will identify both themselves and their OpenID Provider. Their
OpenID provider will then be supplied with the obtained identifier and it will perform
Three
-
T
ier

Service Orientated
System







Page
24


its own authorisation process. The result will either return a success or failu
re me
s-
sage that will subsequently either allow or deny access to the prototype.

Alternatively,

the user can attempt to login utilising the standard login functionality
provided by the prototype
. The
Membership
(Microsoft, 2010)

and FormsAuthentic
a-
tion

(Mic
rosoft, 2010)

class
es

incorporated as part of the
ASP.NET

framework

will
provide the authentication method utilised in the standard login functiona
l
ity.

Figure 3.3.1.1 below depicts the logic performed for authentication selection process.




Figure
3.3.2
.
1

-

Authentication Selection Logic

3.3.3

Control Flow

Once a user has selected an authentication option, the relative authentication pro
c-
ess should be executed. If the OpenID authentication option was chosen then

the
client will be redirected temporarily to the users OpenID provider
. T
heir pr
o
vider will
request proof of identity, where if successful
,

a session will created with the pr
o
vider
who will then redirect the client
along with an authentication success me
s
sage to the
Three
-
T
ier

Service Orientated
System







Page
25


prototype which will detect the success message and subsequently authent
i
cate the
user into the
prototype.

If the
user however selected the standard login option
,

then

the ASP.NET Membe
r-
ship class will process the authentication request. I
f

a
uthentication is

su
c
cessful

the
FormsAuthentication

(Microsoft, 2010)

class

will

be

invoke
d that
will subsequently
create a user se
s
sion.


Figure
3.3.3
.
1

-

Authentication Control Logic

3.3.4

Authorisation Control
Flow

Solely implementing authentication methods provides an inadequate level of sec
u-
rity, for this reason and those described in the Literature Review, a form of access
co
ntrol should be implemented.

When

the prototype receives

a client request

for

a restr
icted
resource
,

the identity of
the user should initially be authenticated. If a valid session is not
detected

then the
cl
i
ent should be redirected to the
authentication (login) page and request they chose
a method of authentication to be performed (as de
scribed in
chapter

3.4.1). Ho
w-
Three
-
T
ier

Service Orientated
System







Page
26


ever assuming a valid session was detected the
users role within the prototype
should be
validated

and based upon the result message, success or failure, the user
should

be allowed access to the requested resource
.

Validation

of a users role within
the o
r
ganisation will be performed by the ASP.NET RoleProvider

(Microsoft, 2010).


Figure
3.3.4
.
1

-

Authorisation Control Logic

3.3.5

Session Termination Logic


3.3.6

Web Interface for Authentica
tion Selection

When attempting to authenticate (login) with the prototype, a user should initially be
directed to the authentication selection page (login.aspx). From this page the user
can select a suitable method of authentication, either via the standa
rd login functio
n-
ality provided by the prototype or using the OpenID Federated Identity Management
option.

Three
-
T
ier

Service Orientated
System







Page
27



Figure

3.4.6.
0
.
1

-

Authentic
a
tion Selection

Design

If the user opts for the OpenID option the cli
ent should be red
i
rected to the OpenID
authentic
a
tion screen (OpenID.aspx) where the user will be prompted to authenticate
with the OpenID identifier.




Figure
3.4.6
.
0
.
2

-

OpenID Authentication Screen

Desig
n


3.3.7

Default Screen Design

If a user is succes
sfully authenticated the client will be redirected to a default user
page (default.aspx). For the prototype this page will be blank other than navigation
links to resources. The navigation links shown however w
ill be limited to only those
that the user has authorisation to access based on the user‟s role within the prot
o-
type.

Three
-
T
ier

Service Orientated
System







Page
28


As an example if the user has the role „heartrate
-
monitor‟, a navigation link directing
the cl
i
ent to „heartrates.aspx‟ will be displayed.

However navigation links to other
resources should not be displayed assuming the user is not associated to the r
e-
quired role.


Figure
3.3.7
.
1

-

Default Screen Design

3.3.8

Restricted Resource Screen Design

The r
estricted resource design in figure 3.4.8.1 below is a generic design. Each r
e-
stricted resource page is associated to a
service, which

follows the Service Orie
n-
tated Architecture design pattern that was
discussed earlier in the report. The
screen should
provide the user with navigational links associated to their authorised
role
,

along with the data associated with the resource they requested.


Figure
3.3.8
.
1

-

Restricted Resource Scree
n

Design

Three
-
T
ier

Service Orientated
System







Page
29


3.3.9

Access Denie
d Screen Design

Whenever a user directs the client towards a resource that requires authentication or
a specific authorisation attribute, the client should detect this as per the authorisation
control flow and redirect the client to screen that informs the

client that access is b
e-
ing denied. If the request is denied due to an authentication error, such as the lack
of a valid session, then the screen should also provide the functionality required to
authenticate. Otherwise the user should be informed that
access has been denied
due to authorisation restrictions.


Figure
3.3.9
.
1

-

Access Denied Screen Design

3.3.10

Membership Database Schema

The presentation tier will utilise a database to maintain users and their i
nformation,
such as role within the prototype. This database will be created by using the as
p-
net_regsql.exe tool that is provided as part of the Microsoft.NET framework.

3.4

Logic Tier

The logic tier is to implement a Service Orientated Architecture (SOA) w
ritten in C#
using the .NET platform. The reason for this is that although other languages and
platforms have their own implementations of
the
SOA design pattern, the .NET pla
t-
form incorporates the Windows Communication Foundation


3.4.1

Service
s

The Service Or
ientated Architecture design pattern lends itself the concept of sep
a-
ration of duty, therefore a service will be required for each of the duties to be pe
r-
formed by the prototype.

Three
-
T
ier

Service Orientated
System







Page
30


Services will be developed around the WCF concept of
contracts, of which ther
e are
four contract types:



ServiceContact


A service contract will define the namespace of a service
along with the operational contracts that service must employ.



OperationContract


Operation contacts will define the methods and data
types for each meth
od that a service must employ.



DataContract


Data contracts provide a formalised agreement between the
service and the consumer. It defines the data that is to be exchanged.



MessageContract


Message contracts will allow define a specific format for
each

message exchange via SOAP.

A contract class library project will be developed that will provide all the service co
n-
tracts, each individual service will then have a project of its own that will define a r
e-
alisation of the service
, implementing the associat
ed service contract interface

and
creating a

communications

bind between the service contracts and the service co
n-
sumer.

Communication will be performed using XML and SOAP, WSHttpBinding‟s will be
uti
l
ised to create the bind between service and consumer.
The reason for using the
WSHttpBinding over another form of binding such as a TCP binding is that the HTTP
binding preserves interoperability.

3.5

Data Tier

The prototype will make use of simulated NHS patient data that is comprised of heart
rate, temperature,

oxygen saturation, blood pressure and respiratory variables.

A
p-
proximately 500,000 records will be simulated, separated into their respective fields
and imported into a Microsoft SQL database. For this prototype the database will be
particularly flat no
t utilising any form of normalisation, rationa
lisation or entity rel
a-
tionship and will instead employ a single table holding all data.

3.5.1

Patient Simulation Data
Table

Schema

The figure below is a simplified design concept of what the patient simulation data
database schema should be. It should contain a unique record identifier (UID), a
unique patient identifier (PID) a columns for each of the simulated data properties
(heartrate, temperature, bloodpressure, respiratory, oxygensaturation).

Three
-
T
ier

Service Orientated
System







Page
31



Figure
3.5.1
.
1

-

Patient Simulated Data Database Schema

3.6

Conclusion

The primary objective of the Design & Methodology was to provide a skeletal te
m-
plate to be
referenced

during the implementation phase whilst documenting the
choices made in the fulfilment for providing secure access to resources in a user
centric format.

Confidentiality and Integrity for the presentation tier has been mai
n-
tained through the i
n
clusion of an OpenID trust partnership and utilisation of the pre
-
d
efined well tested Microsoft.NET helper classes FormsAuthentication, Membe
r-
shipProvider and RoleProvider.

Message communication between the presentation tier and logic is tier is preserved
through the use of Microsoft.NET WCF WSHttpbinding that provides se
cure reliable
messaging and WCF service contracts that define the format for messages defen
d-
ing against spoofed messages and eavesdropping.

The data tier is not directly accessible and does not accept query string based r
e-
quests the user might attempt to i
nput into a browser address bar. This means only
query requests defined by the prototype are executed
,

preventing data attacks such
as inference

that

would be a breach of confidentiality
,

and therefore not fulfil the r
e-
quirement of a secure resource.

Wit
hin the Membership database no sensitive data
is to be store in plain text format and instead will utilise encryption techniques.

Three
-
T
ier

Service Orientated
System







Page
32


4

Implementation

4.1

Introduction

This chapter documents how the

prototype applicable technologies identified in the
conclusion of t
he Literature Review chapter could potentially be implemented as a
„proof
-
of
-
concept‟. Code extracts will be provided where applicable to assist in the
description of the impl
e
mentation methods.

4.2

Presentation Tier

The following sub
chapter
s document the pr
esentation
tier implementation and refer
to the methodology and design choices made in the Methodology and Design
cha
p-
ter

above.

4.2.1

Prototype Web.Config

The prototype presentation tier is based around authentication and authorisation, this
is performed by the

ASP.NET FormsAuthentication, MembershipProvider and R
o-
leProvider. The functionality of these helper classes can be manipulated to specif
i-
cation based on the requirements of your application.
Chapter

8.2

is the XML code
from the prototypes Web.Config fil
e which specifies how these helper classes should
function.

4.2.2

Web Interface for Authentication Selection

The web interface for authentication selection screen, as shown below, contains two
methods for authentication as per the design in the previous
chapter
.

The standard
login and a separate option to utilise OpenID. The OpenID option was added as a
separate link so as not to confuse users with two distinct login options on a single
page.


Figure
4.2.2
.
1

-

Web Interface for Authentication Selection Screenshot

Below is a code extract from the login.aspx file that shows the implementation of the
Membership and FormsAuthentication helper classes from ASP.NET.

Three
-
T
ier

Service Orientated
System







Page
33


protected

void

btn_log
in_Click(
object

sender,
EventArgs

e)


{


Page.Validate();


if

(!Page.IsValid)


{


return
;


}


if

(
Membership
.ValidateUser(
this
.txt_username.Text,
this
.txt_password.Text))



{


// disable persistant cookie


// kills cookie when browser is closed (doesn't include tabs)


// increases security due to numereous reasons i.e. decreases proba
b-
lity of session hijacking


F
ormsAuthentication
.RedirectFromLoginPage(
this
.txt_username.Text,
false
);


}


else


{


this
.lbl_status.Visible =
true
;


}


}


4.2.3

Default Screen

When a user is authenticated within the prototype,

the client is redirected to the d
e-
fault „portal‟ page. For the prototype this page is blank other than navigational links

associated with the users role within the prototype.


Figure
4.2.3
.
1

-

Default Scre
en Screenshot

4.2.4

Restricted Resource Screen

Restricted resources is a generic term used for a web page within the authenticated
realm of the prototype that provides information obtained from a service. Each se
r-
vice is separated into a singular
resource page
with

the retrieved content in the ce
n-
ter

and navigational links associated with the user role at the top.


Figure
4.2.4
.
1

-

Restricted Resource Screen Screenshot

Three
-
T
ier

Service Orientated
System







Page
34


The code extract below

is an example of the m
ethods that are invoked when a user
navigates to a resource. In this example patient heart rates are being retrieved from

database and bound to a ASP.NET gridview component.


private

void

PopulateHeartRateGridView()


{


this
._heartRateAr
rayMessage =
this
._heartRateService.GetHeartRates();


DataTable

dt =
new

DataTable
();


dt.Columns.Add(
"Pid"
);


dt.Columns.Add(
"Heartrate"
);


DataRow

dr;


for

(
int

i = 0; i <
this
._heartRateArrayMessage
.HeartRates.Count(); i++)


{


dr = dt.NewRow();


dr[
"Pid"
] =
this
._heartRateArrayMessage.HeartRates[i].Pid;


dr[
"Heartrate"
] =
this
._heartRateArrayMessage.HeartRates[i].Heartrate;


dt.R
ows.Add(dr);


}


dt.AcceptChanges();


this
.gv_heartrates.DataSource = dt;


this
.gv_heartrates.DataBind();


}


}


4.2.5

Access Denied

Whenever a resource is requested by the client on behalf of the user, the p
rototype
performs the authorisation process as described in the above
chapter
. If the user is
not authorised to view the requested resource the client is redirected to the access
denied web page. A screenshot of the access denied page can be seen below (
fi
g-
ure 4.2.4.1).


Figure
4.2.5
.
1

-

Access Denied Screen Screenshot

4.3

Logic Tier

4.3.1

Service Contract Realisation

Each of the patient simulated data properties (heartrate, temperature etc) is sep
a-
rated into individ
ual services. This not only follows SoA design principles but makes
the services easier to manage as logic is separated and makes
access authorisation
easier.

Three
-
T
ier

Service Orientated
System







Page
35


The figure below is an example

class model

of the implementation of the heartrate
service which
is contained within the solution class library. The service has an inte
r-
face that defines the ServiceContract and OperationContract(s) that the service must
i
m
plement.

The HeartRateArrayMessage and HeartRateMessage classes define the
MessageContract(s) w
hilst the HeartRate class defines the properties of each me
s-
sage.


Figure
4.3.1
.
1

-

Service Contract Class Realisation

An example of the IHeartRateService interface is provide
d below however further
code implementation can be located in the appendix.

namespace

Contracts

{


[
ServiceContract
(Namespace=
"http://tempuri/heartrate"
)]


public

interface

IHeartRateService


{


[
OperationContract
]


HeartRateMessage

RetrieveHeartRateRecord(
HeartRateMessage

message);



[
OperationContract
]


HeartRateArrayMessage

RetrieveAllHeartRateRecords();



[
OperationContract
]


String

TestDBConnection();



[
OperationContract
]


String

Service
ToString();


}

}


4.3.2

Service Realisation

The service contracts as defined above only provide the skeletal framework for the
service to be implemented. An actual implementation of each service must then be
implemented, this service provides the inner worki
ng of the OperationContract(s) d
e-
fined in the service interface as well as service connectivity properties such as the
socket information and binding information. Figure 4.3.2.1 below is a class model of
the HeartRateService. The Program class is respons
ible for creating the binding and
instantiating the service, whilst HeartRateService performs any logic (such as the
Three
-
T
ier

Service Orientated
System







Page
36


retrieval of heartrate data).

Example code of the program file is given below with fu
r-
ther code provided in the appendix.

namespace

HeartR
ateService

{


class

Program


{


static

void

Main(
string
[] args)


{


// Create the address


Uri

address =
new

Uri
(
"http://localhost:8003"
);


// Create the binding


WSHttpBinding

binding =
new

W
SHttpBinding
();


// Create the service object


HeartRateService

service =
new

HeartRateService
();


// Create the host


ServiceHost

host =
new

ServiceHost
(service, address);


// Add the endpoint



host.AddServiceEndpoint(
typeof
(
IHeartRateService
), binding,
"heartrate"
);



// Open the host


try


{


host.Open();


Console
.WriteLine(
"Heart rate service started"
);


Console
.WriteLine(
"Press return to exit"
);


Console
.ReadLine();


// Close the host


host.Close();


}


catch

(
Exception

ex)


{


Console
.WriteLine(
"Error opening a connecti
on to the service: "

+
ex.Message.ToString());


Console
.WriteLine(
"Press return to exit"
);


Console
.ReadLine();


}


}


}

}



Figure
4.3.2
.
1



Service Class Realisation

Three
-
T
ier

Service Orientated
System







Page
37


See the appendix for 8.2 for the
complete
code utilised in this example implement
a-
tion.

4.4

Data Tier

4.4.1

Database
PatientSimData Table
Schema

A new database was created within an instance of Microsoft SQL server, the fo
llo
w-
ing SQL query was then executed within the database instance to create the r
e-
quired table for holding the patient simulated data:

CREATE

TABLE

[dbo]
.
[PatientSimData]
(


[UID] [varchar]
(
50
)

NULL,


[PID] [varchar]
(
50
)

NULL,


[HeartRate] [varchar]
(
50
)

NULL
,


[Temperature] [varchar]
(
50
)

NULL,


[BloodPressure] [varchar]
(
50
)

NULL,


[Respiratory] [varchar]
(
50
)

NULL,


[OxygenSaturation] [varchar]
(
50
)

NULL

)

ON

[PRIMARY]

4.5

Conclusions

The use of the Microsoft.NET framework significantly simplified the development o
f
the prototype

through the utilisation of the FormsAuthentication, Membershi
p-
Provider and RoleProvider helper classes.

The ASP.NET aspnet_regsql.exe did
however limit the choice of database to only MSSQL and pre
-
specified how the
membership database sche
ma should defined. Although this is acceptable for the
prototype a further developed system might want the ability to change aspects of the
database. This would require significant work on the developers part which although
not impossible might prove cos
tly. The use of custom authentication and authoris
a-
tion techniques could have been implemented from the start however this would
have increased development time and the helpers provided have been significantly
tested over time.

The use of Microsoft Expre
ssion Blend+Sketchflow was a major
benefit to the implementation phase, the mock page designs shown in the design
and methodology chapter along with the “flow” diagram that was provided by sketc
h-
flow made the implementation phase significantly less complic
ated to follow.



Three
-
T
ier

Service Orientated
System







Page
38


5

Evaluation

5.1

Introduction

This
chapter

documents the evaluation methods performed on the prototype in rel
a-
tion to the aims and objectives of the project.

It documents a selections of tests that
were performed upon the prototype in an effo
rt to stress and eventually find the fail
-
stop error point of the prototype. The tests are performed by retrieving a specified
quantity of records and columns from the database and measuring the time taken
between invoking a call and receiving a response.


It should be noted that the performance evaluations were performed within a virtual
machine on an Apple MacBook Pro with the following specific
a
tion:



Intel Core2Duo 2.2GHz



4GB 667MHz DDR2 SDRAM



800MHz FSB



120GB HDD



OSX Leopard 10.5.8



VMWare Fusion 3.1.1

o

Windows 7

o

2GB 667MHz DDR2 SDRAM

o

40GB HDD

o

MSSQL Server 2008 R2

o

Visual Studio 2010

o

Microsoft.NET 4


5.2

Stress

Evaluation

To perform the stress
evaluation

a stopwatch was implemented within the prototype
code. This was placed at three strategic points within t
he prototype so as to provide
the most accurate results.

Three
-
T
ier

Service Orientated
System







Page
39


SQL statement execution


A stopwatch counter was placed around the SQL exec
u-
tion statement in the logic tier. This measure the time elapsed during SQL exec
u-
tion.

SQL method invocation


A second ti
mer was placed around the statement in the
presentation tier code that invokes the SQL execution statement within the logic tier.
This measures the round trip time elapse between invocation and retrieval.

Data output


A final timer was started the statem
ent in the presentation tier code
that i
n
vokes the SQL execution statement within the logic tier, and closed after the
code which rendered the returned data to the screen. This measures the round trip
time elapse between invocation and presentation.

5.2.1

Preli
minary Testing

This set of tests was very basic starting with 100 records and three columns, the
r
e-
source page was
initially loaded

and then reloaded a further four times each time
ta
k
ing not
e

of the elapsed time as provided by

the stopwatch.

This process

was r
e-
peated for 500 and 1000 records
,

each time taking note of the elapsed time for each
of the tiers
.

Table 5.2.1.1 and figure 5.2.1.1 both show the results set for the same elapsed time
evaluation.


1

2

3

4

5

100

0.012279

0.01612

0.01359

0.797187

0
.844185

500

0.018793

0.013139

0.011681

0.01284

0.015086

1000

0.331426

0.027108

0.010325

0.012821

0.021002


Table
5.2.1
.
1
-

Stopwatch results 100
-

1000 records


Three
-
T
ier

Service Orientated
System







Page
40



Figure
5.2.1
.
1

-

Stopwatch

results 100


1000 records




1

2

3

4

5

100

10.31381

0.537253

0.586773

0.361876

0.373255

500

5.898847

0.773543

0.230963

0.142069

0.113503

1000

6.300116

0.257319

0.144576

0.163387

0.141109


Table
5.2.1
.
2

-

Stopwatch results 100


1000 records without data render


Figure
5.2.1
.
2

-

Stopwatch results 100


100
0

records

without data render



1

2

3

4

5

Three
-
T
ier

Service Orientated
System







Page
41


100

10.54924

0.545331

0.596118

0.383428

0.383037

500

5.926228

0.84041

0.257712

0.155801

0.
127596

1000

6.328515

0.290831

0.176374

0.189466

0.169152


Table
5.2.1
.
3

-

Stopwatch results 100


1000 records with data render