Clinical Dashboards
SmartCard Security Solution
10 June 2010
SmartCard Security
1.
2.
3.
4.
5.
6.
7.
Requirements
Solution Summary
Process Flow
Process Notes
Deployment Plan
Estimated Costs
Contacts
Appendices
2
1. Requirements
Clinical Dashboard Programme: Statement of Requirements - Security
• A number of options must be supported by the Pilot technology solution including Single Sign On integration with
the Other Service Recipient domain (Active Directory or Novell); and username and password access where the
former is not possible.
• The intention for the potential national rollout is to utilise the National Spine Security Broker (SSB) to provide the
single sign on authentication and authorisation services.
Connecting for Health: Statement of Requirements - Information Governance
The NHS CFH Compliance Scheme has been developed to facilitate the connection of existing systems to the
national application services of NHS CFH. Information Governance is a key aspect of the NHS CFH requirements
for systems, reflecting for example the commitments made under the Care Record Guarantee and the NHS
Confidentiality Code of Practice1.
The underlying principle of the Compliance Scheme is to ensure that such systems meet the Authority’s functional
business requirements and in particular, that systems adhere to non-functional requirements in the areas of
security, information governance, Caldicott principles, message and messaging interface specifications.
The requirements are documented in NPFIT-FNT-TO-TIN-0427.10 IG Requirements for ESP Systems v5.0:
NHS Trust: Statement of Requirements - Security
• Any Trust requirements should be reviewed individually.
3
2. Solution Summary
The Clinical Dashboard - Smartcard Security Solution deployed at Bolton PCT demonstrates that Clinical
Dashboards can be compliant for use of SPINE single sign-on via integration with the SPINE Security Broker
through implementation of single sign on integration using a Microsoft Intelligent Application Gateway (IAG) for
the Clinical Dashboard utilising the existing Smartcard infrastructure.
The solution deployed at Bolton PCT uses a Microsoft Intelligent Application Gateway (IAG) appliance configured
by Winfrasoft to integrate with the SPINE and manage access to the System C – Medway Sigma BI based
dashboard through the use of NHS Smartcards. The Microsoft IAG product comes in two forms:
1. a VMware or Virtual PC virtual server instance that can be deployed on any physical server, and
2. a pre-configured dedicated Hardware Appliance from HP or DELL.
The solution deployed at Bolton PCT uses a hardware appliance [HP DL360 GS (7000)] as this supports
significantly more user connections than the potential 200 concurrent users for the dashboard, and is supported
by a Standard Annual Support & Maintenance Agreement from Winfrasoft and an Annual License Fee for the
Winfrasoft IAG appliance configuration.
4
3. Process Flow
The simplest process flow for a ‘Clinical Dashboard Logon with a Smartcard’ is as follows:
1.
2.
3.
4.
5.
6.
7.
The User inserts their Smartcard into the Smartcard Reader.
The Smartcard Reader passes the data to the BT Identity Agent software (2.1) which requests the
associated PIN from the user via the GEMPlus software (2.2 – 2.3).
The BT Identity Agent software connects to the Spine Security Broker (SSB) authentication service and
requests a SPINE Ticket which is returned (if the user is successfully authenticated) and stored in the BT
Identity Agent (along with the Public Certificate and the UID).
When the user then opens a browser and attempts to connect to the Clinical Dashboard URL over HTTPS
(4.1) the DNS service redirects the user to the Microsoft Intelligent Application Gateway (IAG) (4.2) which
requests the SPINE Ticket from the BT Identity Agent software (4.3).
The Microsoft IAG validates the User ID & Session ID from the SPINE Ticket using a SAML Assertion
against SPINE. If the Session ID is not validated by SPINE they will be denied access to the Clinical
Dashboard.
If the Session ID is validated by SPINE the Microsoft IAG will then validate that the User exists in the
Trusts Active Directory (AD) using the User ID and what level of access they should have to the Clinical
Dashboard:
• If they do not exist in the Active Directory they will be denied access to the Clinical Dashboard.
• If they do exist in the Active Directory the Microsoft IAG grants the user access to the Clinical
Dashboard based on the AD Groups associated with the User Account by creating a Kerberos
Constrained Delegation (KCD) secure session for the User with the Clinical Dashboard server to
support the auditing functions, and maintains the mapping between the KCD session and the Users
session with the Microsoft IAG.
When the Users session is terminated (browser is closed or smartcard removed) the
Microsoft IAG terminates the KCD and User sessions.
5
3. Process Flow (diagram)
·
·
·
SPINE
N3 Connected
Key
Spine Auth Traffic
HTTPS Traffic
AD Traffic
PC Software
GEMPlus
2.3
2.2
1
2.1
ID Agent
3
N3
Spine Authenticator
Card Reader
Browser
User
4.1
PC
4.3
4.2
Trust Network
PC Software
GEMPlus
5
2.3
2.2
1
2.1
ID Agent
Active Directory
LAN
3
Card Reader
Browser
User
4.1
6
4.2
Intelligent Application
Gateway
SharePoint
PC
6
4. Process Notes
1.
2.
3.
4.
5.
6.
If the User does not exist in the Trusts Active Directory but should have access to the Clinical Dashboard
they will need to be manually provisioned in the Active Directory with the required Active Directory Groups
before the can access the Clinical Dashboard.
If the user opens a browser and attempts to connect to the Clinical Dashboard URL before they have
inserted their SmartCard then when the Intelligent Application Gateway which requests the SPINE Ticket
from the BT Identity Agent software they will need to insert their Smartcard into the Smartcard Reader
and enter their PIN before the system will continue.
HTTPS is a pre-requisite to secure communications and will require an additional certificate to be
deployed for the IAG appliance, in comparison with the standard HTTPS certificate deployment for Clinical
Dashboards, as the users session will not be ‘passed through’ the gateway, but linked to a separate user
session between the IAG and the Clinical Dashboard.
For the purpose of Public Displays ONLY the IAG appliance is bypassed. The approach uses Active
Directory authentication and the dashboard is configured with a Timed Refresh web part that refreshes
the page ever 10 minutes so the data is always up to date. Any Public Display physically outside of the
Trust domain will need to remotely connect to the domain and the user authenticated with their AD
credentials, e.g. via Citrix.
An Alternative Authentication mechanism is supported that allows users to access the dashboard
application using their Active Directory username and password instead of their Smartcard. This
mechanism can be used by the Administrator to facilitate user access where some users do not possess
smartcards or in the unlikely event that SPINE is unavailable.
GEMPlus v10 works fine with Series 400 smartcards apart from not closing the session / browser window
when the card is removed. The functionality works as expected with GEMPlus v11. The issue can be
addressed by either retrofitting a registry key which fixes the problem or upgrading to v11. Note that v12
of the software is planned to remove the ‘browser close’ functionality and make this the responsibility of
the application. Therefore the registry changes will be required when IA12 is deployed to
stop a change in behavior and re-emergence of the issue.
7
4. Process Notes
7.
The solution does not fully comply with IG Requirements for ESP Systems 3.1.5 & 3.1.6 as there is no
SSO Token Listener to prompt the IAG/HAS solution to “take action as appropriate” when a users SPINE
Session has expired. Once a user’s credentials have been validated against a valid SPINE session the
IAG/HAS solution does not continually monitor the SPINE to determine if the SPINE session remains
valid. Therefore access to and use of the Clinical Dashboard is independent of the continued SPINE
session validity. However controls are implemented within the solution to mitigate this situation and the
position of the Clinical Dashboard Programme and IG Representative following consultation with wider IG
representatives is that while the solution should fully comply with the IG Requirements through
implementation of an SSO Token Listener the nature of the system is such that the risk is low and
approval has been give for deployment of the solution subject to:
• approval from the IG Manager and the Caldicott Guardian for the Trust;
• documentation of the product development roadmap required for implementation of the mechanisms
that would make the solution fully compliant; and
• that the enhanced solution would be made available to all deployments.
8
5. Deployment Plan
This Deployment Plan is an example that would need to be reviewed and updated for each Trust delivery…
9
6. Estimated Costs
The estimated solution component costs (£ exc VAT) based on the pilot would be in the following region:
IAG Appliance Hardware & Software (IAG Gateway on HP DL360 GS (7000))
IAG Appliance Hardware 24x7 Support (HP) / Year
Winfrasoft Standard Annual Support & Maintenance Support / Year
Winfrasoft Configuration & Support / Year
7000
200
2000
600
(£3/user/year inc. support/maintenance)
10
7. Contacts
Microsoft
•
Bill Orme – Microsoft IAG Product Owner
Winfrasoft
•
Ian Shandling – Business Development Director
•
Steven Hope – Chief Technical Architect
11
Appendices
12
Hardware Options
13
Support Options (1/2)
All of the Winfrasoft support offerings have been designed with the end-user in mind. As with all good support
offerings, 9am to 5.30pm first line support is the responsibility of the reseller, the owner of the relationship. Winfrasoft
provides resellers with training to ensure that 1st-line support issues will be professional dealt with. In cases where
the 1st-line support does not address the issue, an outline of the problem will be emailed to Winfrasoft Support who
will in return send you a ticket number and will aim to resolve the problem within 24 hours.
Hardware related issues will be addressed by an engineer at the End User’s site to replace the defective part.
Software related queries will then be escalated to a highly skilled team of trained Microsoft Product and Security
Specialist experts capable of providing both telephonic and email assistance. In extreme circumstance where the
potential fix is more problematic, extra time may be required to replicate the issue or a Winfrasoft Product Specialist
may need to remotely connect to the defective Winfrasoft Appliance1.
Support Options
Standard
Enterprise
Winfrasoft Appliance Image Updates
Email Support
Engineer on-site hardware support (8 x 5)
Engineer on-site hardware support (24 x 7)
Direct Access specialist telephone support
Appliance self-monitoring
Remote Access Support
(1) This offering is dependent on the configuration of the monitoring agent on the Winfrasoft Appliance and end-user policy allowing access to Winfrasoft Appliances.
14
Support Options (2/2)
8x5 Support: recommended for organisations that have IT departments that deploy Winfrasoft Appliances as point
solutions and have sufficient technical resources to cope with day-to-day operational issues. Support is provided via
phone and email during normal working hours and an engineer on site next day for hardware issues.
24x7 - 4 Hour Response Support: for organisations that have more complex deployments, or, have limited internal
skills specific to the Winfrasoft Appliance deployment, but whose company works around the clock, should consider a
24-Hour customer support package. 24-Hour support delivers technical support 24 X 7 with a maximum 4-hour
response time via phone & email and an engineer on site within 4 Hours for hardware issues.
Prerequisites: software must be at current release or one release previous.
Dependencies: third-party software applications must have associated software subscription coverage and support
program to be supported and may only be supported by that vendor.
Lead Time: immediate activation upon successful registration of service agreement receivables:
• Purchase Order.
• Support registration of Service Agreement by Reseller.
End-customer Responsibilities:
• Maintain software at current release, or no later than one (1) release previous.
• Provide accurate site location, contact and specific product information and notify Winfrasoft of equipment move.
• Maintain personnel with adequate technical expertise and training to assist Winfrasoft with troubleshooting and
problem resolution.
Exclusions: the service does not cover the following:
• Altered product, except as authorised by this agreement and Winfrasoft.
• Servers that have been upgrade with non approved parts.
• Products installed, operated, or maintained not in accordance with specifications supplied by Winfrasoft.
• Products subjected to unusual physical or electrical stress, misuse, negligence or accident, or used in ultrahazardous activities in conjunction with the hardware manufacturers guidelines and restrictions.
• Out of revision products (or products shipped more than 36 months prior to contract initiation).
15
Supporting Documentation
Additional documentation from the Smartcard Security Solution Pilot is available upon request from the Clinical
Dashboard Programme PMO:
Stage
Document
2 Scoping
Smartcards - Release Scope Definition
2 Scoping
Smartcards - IG Compliance Matrix
3 Development
Winfrasoft - IAG Server Gateway Quick Deployment Guide
3 Development
Winfrasoft - HAS Installation and Configuration Guide
3 Development
Winfrasoft - HAS TAG Spine Card High Level Design
3 Development
Smartcards - Test Strategy
3 Development
Smartcards - Test Specification
3 Development
Smartcards - Test Plan
3 Development
Smartcards - Incident Report Template
3 Development
Smartcards - Test Environment Diagram
3 Development
Smartcards - NIS1 System Test Report
3 Development
Smartcards - NIS1 System Test Release Note
3 Development
Smartcards - NIS1 System Test Scripts
3 Development
Smartcards - Integration Test Plan
3 Development
Smartcards - Integration Test Report
3 Development
Smartcards - Integration Test Release Note
3 Development
Smartcards - Integration Test Scripts
4 Prepare and support Go Live
Smartcards - RFO Checklist
16