Request for Proposal (RFP)
DSF01-067
APPENDIX A – CUSTOMER SPECIFICATION
This document forms Appendix A to the Request for Proposal (RFP) for Digital Services Framework
Agreement – RM1043, along with Pricing Matrix (Appendix B) and an Award Questionnaire (Appendix C).
CONTENTS
PROJECT START DATE AND TIMEFRAME
CURRENT SITUATION/ BACKGROUND INFORMATION
REQUIRED OUTCOMES
USER NEEDS
CAPABILITIES AND ROLES
PRICING MODEL
CUSTOMER LOCATIONS
TEST & DEVELOPMENT REQUIREMENTS
Digital Services Framework Agreement - RM1043
Document1
Page 1 of 29
Request for Proposal
Digital Services Framework Agreement – RM1043
PROJECT START DATE AND TIMEFRAME
The timescales below reflect the urgency in delivering an IDAM solution to the Common Platform Programme.
Due to this being on the critical path we cannot allow slippage in these dates.
Key delivery dates
PROJECT PHASES
START DATE
COMPLETION DATE
RFP
15/08/14
29/09/14
Discovery
06/10/14
17/10/14
Alpha
20/10/14
28/11/14
Beta
We reserve the right to continue
into this phase depending on the
outcome of the Alpha phase
Live
We reserve the right to continue
into this phase depending on the
outcome of the Beta phase
CURRENT SITUATION / BACKGROUND INFORMATION
Introduction and Context
Her Majesty's Courts & Tribunals Service (HMCTS) and the Crown Prosecution Service (CPS) have
established the Criminal Justice System (CJS) Common Platform Programme (CPP) as a joint initiative to
define and implement IT-enabled transformational business change within the CJS spanning the CPS,
Magistrates’ and Crown Courts. The CJS CPP will play a key role in delivering IT-enabled business change
that, in combination with other delivery programmes, will reform the CJS. It will also build a capability within
the business for IT-enabled change so that the business can be more responsive and agile in the future.
The long term strategic approach to provision of an Identity and Access Management (IDAM) solution for the
CJS CPP has identified the Government Digital Service (GDS) Identity Assurance (IDA) Programme and a
future service provided by the Public Service Network (PSN), as good strategic fits with the Common
Platform, covering different aspects of the user base. However until the GDS IDAP and PSN services are fully
available and implemented alternative interim authentication services will need to be found to cover the
immediate needs of services wishing to use the CJS CPP, including specific recommendations for how this
should be achieved. These interim services will be replaced by the PSN and GDS services when they are
available.
Additionally there is a need to for a central core service for the Common Platform that will provide matching,
user and account management and directory services. These services will be longer term strategic solutions
that will not be replaced in the foreseeable future. This Digital Services Framework procurement focuses on
provision of the central core service.
The overall IDAM solution comprises a number of components, including the identification and registration,
and enrolment and authentication capabilities that enable appropriate stakeholders access to the Common
Platform services. The IDAM solution does not include the role-based control required for fine-grained
authorisation, which remain the responsibility of specific applications/services.
Digital Services Framework Agreement - RM1043
Document1
Page 2 of 29
Request for Proposal
Digital Services Framework Agreement – RM1043
The IDAM Solution Overview
A high-level overview for the IDAM solution is set out below in Figure 0-1 as a service specification for the
elements to support the immediate activities of the programme. This shows a strategic architecture integrated
with the Government Digital Service (GDS) Identity and Access (IDA) Hub. This strategic architecture is
augmented with interim Authentication Providers (for professional users, including those in organisations, via
Internet access and for Public Service users via secure access) that will need to be put in place pending
implementation of the full IDA and Public Sector Network service capability.
Figure 0-1: Strategic high-level design and Interim IDAM service
The Common Platform Central Service (in the Central zone) is the Service Provider. It consists of the
Common Platform Point of Access and the various applications and components that together provide the
Common Platform capability. Users will connect with this service directly to access Common Platform
functionality. On initial connection, they may be subsequently redirected to the appropriate identity provider for
authentication. The CP service also includes the functionality required for user account management for both
general users and administrators.
The authentication token from the IdP will be passed to the Common Platform, that will consult a master
directory (CP Directory) of authorised Common Platform users and their account details. The consultation will
determine whether the authenticated user is entitled to access the Common Platform. The CP Directory will
also contain the list of CP Applications that the user is entitled to access. When a successful match is found,
the user will be passed through the Point of Access to the corresponding application (not shown on the
diagram) along with a Common Platform Unique Identifier (CPUI). An Account Management service will be
required to support the user account management process. Synchronisation of user profile and account
Digital Services Framework Agreement - RM1043
Document1
Page 3 of 29
Request for Proposal
Digital Services Framework Agreement – RM1043
management data will be required with the Common Platform Applications to ensure that there is a single set
of data for each user.
Over time there will be multiple Identity Providers interacting with the Common Platform, including through
both IDA and the future Public Sector Network service. It will be possible for individual users to be registered
with multiple Identity Providers concurrently.
Current artifacts
The ‘IDAM overall context’ diagram illustrates the example user types requiring authentication and access to
the applications.
1) Users can access applications using various devices e.g. trusted and untrusted PCs, tablets and
phones.
2) User authentication is required via one of the recognised IdPs.
3) The user’s credentials are matched in the IDAM’s identity checking component. On successful logon,
IDAM will check its directory store for applications which the user will have access to.
4) The user will be directed to the requested application, which can be located on trusted or untrusted
networks as well as on the internet. The applications can be COTS, bespoke or applications on the
cloud.
Digital Services Framework Agreement - RM1043
Document1
Page 4 of 29
Request for Proposal
Digital Services Framework Agreement – RM1043
IDAM Identity Providers (IdPs)
 Interim Internal IdP – this is an interim component which will eventually be replaced by a PSN service.
The internal IdP identifies internal users e.g. users already with access to the Public Sector Network
(PSN).
 Professionals/Organisations IdP - identifies organisations and legal professionals e.g. magistrates.
 GDS IDA – this is a Cabinet Office program which will register and issue credentials to citizens over
the Internet.
Core IDAM Components
 Point of access/interface – this is the single route into IDAM. It forwards unauthenticated users
through to the appropriate IdP. Authenticated users are presented with links to applications in
accordance with their access “policy”.
 Identity matching – this component matches IdP users to CJSCP users and determines whether a
user exists in the IDAM layer.
 Directory – this is the directory store which persists user attributes, applications that the user has
access to and a unique id (CPP Id). A user is granted access to an application by checking whether
they exist in the directory store and are forwarded to the requested application if they have access to
it.
 User access management – this manages the provisioning, editing and decommissioning of user
access.
Applications
Digital Services Framework Agreement - RM1043
Document1
Page 5 of 29
Request for Proposal
Digital Services Framework Agreement – RM1043



MCR – Magistrate’s Court Rota application, this will be one of the initial applications that will interface
with the IDAM to determine access control.
Store – a document store which will hold court papers and documents, this will be one of the initial
applications that will interface with the IDAM to determine access control.
Apps #n – Other applications and services will gradually interface with the IDAM to determine access
control.
Individual applications and services will be responsible for their own RBAC.
Digital Services Framework Agreement - RM1043
Document1
Page 6 of 29
Request for Proposal
Digital Services Framework Agreement – RM1043
As a user e.g. member of the general public, magistrate, a delegated personnel from a legal firm, an internal
user (these users may already have access to the PSN or GSI) requiring access to the applications, a process
of enrolment and verification is required.
The user starts this process by accessing a common interface in the IDAM layer which will check using an
identity matching component whether they are already registered with a recognised IDAM Identity Provider
(IdP).
If the user is not registered with an IdP then they must register with one of the recognised IdP before they can
access the applications. Their credentials are captured by IdP and passed onto IDAM which produces a
unique Common Platform Programme (CPP) Id. The CPP Id and other attributes for the user will be required
to configure what application the user has access to at the IDAM layer. This information is then passed onto
the application layer in order to configure the role based access control (RBAC) for each application that the
user has access to.
If the user is already registered with a recognised IdP, then the identity matching component will check the
directory store for the type of applications that the user has access to. Where the user does not have access
to a required application, access to the application will be configured in the IDAM layer using their CPP Id.
The user’s attributes and their CPP Id will then be passed to the application layer for RBAC configuration.
As an IDAM administrator, the adminstrator can change user records held in the directory store. All user
changes from IDAM e.g. user attributes or the applications they are allowed access to will have to be
synchronised with the applications as the directory store is the master directory of CPP users.
Digital Services Framework Agreement - RM1043
Document1
Page 7 of 29
Request for Proposal
Digital Services Framework Agreement – RM1043
Users can access the system via the IDAM Point of Access/Landing page or directly via the application’s URL.
If a user is already authenticated (using an IdP), the user will be forwarded to the required application.
If the user is not authenticated and has originated from a trusted network, the user will need to be use the
Interim Internal IdP and on successful logon will be forwarded to the required application or the common
interface.
If the user is not authenticated a wants to access as a professional or a delegate of an organisation, the user
will use the Professional IdP and on successful logon will be forwarded to the required application or common
interface.
If the user is not authenticated a wants to access as a member of the public the user will be directed to the
GDS IDA. On successful logon, they will be allowed access to the required application or common interface.
Access will be denied to users with unsuccessful IdP logins.
Digital Services Framework Agreement - RM1043
Document1
Page 8 of 29
Request for Proposal
Digital Services Framework Agreement – RM1043
As an IDAM administrator, a request has come from the business to remove access to applications for a user.
The user will have their access removed from IDAM’s directory store, this needs to be synchronised with the
application RBAC. After an appropriate duration, the user record will be deleted from the IDAM’s directory
store, again this needs to be synchronised with the application RBAC.
Digital Services Framework Agreement - RM1043
Document1
Page 9 of 29
Request for Proposal
Digital Services Framework Agreement – RM1043
The ‘Providing the access mechanism to application/services’ wireframe illustrates the provisioning of the
users on the CJSCP. Where labelled with ‘Provided by GDS’, ‘Provided by IdP’ or ‘Provided by app’, this
indicates the mechanisms are already in place and are outside the scope of the procurement requirements.
Digital Services Framework Agreement - RM1043
Document1
Page 10 of 29
Request for Proposal
Digital Services Framework Agreement – RM1043
Current Roles and Responsibilities of the Customer
The CJSCP IDAM Project Team is made up of:
Elizabeth King/Chris Grice – Project Manager
Keith Holder – IDAM Subject Matter Expert
James Sadler – Solution Architect
Christine Chan – Business Analyst
Jacques de la Porte – Information Security Architect
TBC – Test Analyst
Current Technologies and Languages
Open source technologies and products are preferred. The first two applications to use IDA will be:
 Magistrates Court Rota: Bespoke web-based application written in HTML, JavaScript and JAVA.
Currently uses OpenAM for Access Management
 Store: A web-based document store based on an Open Source DRMS (Alfresco).
REQUIRED OUTCOMES
Requirements Context and Outcomes
The overall IDAM solution is broken down into 3 sections (Lots). However it should be noted that the current
procurement through the Digital Services Framework (DSF) is only for Central IDAM Services (Lot 3). Lots 1
and 2 (IDPs) are being procured separately through the G Store. Lots 1 and 2 are provided here to set the
context for the current DSF procurement, the outcome of which is to provision a service that will provide all the
functionality of the IDAM Central Service (Lot 3).
Lot 1: Identity Provision and Authentication Solution for external users via the Internet, including:
a) Individuals acting in a professional capacity, initially Magistrates (required within 3 months);
b) organisations, such as legal firms, and individuals (e.g. defence lawyers and solicitors) within them
(within 6 months);
Lot 2: Identity provision and authentication solution for Public Sector Staff (e.g. those within HMCTS and CPS)
(required within 6 months);
Lot 3: IDAM Central Service (required within 3 months), consisting of:
a)
b)
c)
d)
Point of Access to provide a ‘front door’ to the Common Platform applications.
Matching Service to validate identities provided by external identity providers;
Directory Service to provide a master repository of user details;
Enrolment, Access and Account Management Service to enable users and administrators to access
and manage account details.
A full set of requirements is attached in Addendum A.
Approach and methodology
The CJS CPP has adopted an Agile approach to developing the services. The IDAM solution will be
developed in 3 distinct phases (Discovery, Alpha and Beta), with Discovery phase setting the scope for Alpha
testing. Those responding to this specification should follow that approach and provide proposals for each
phase of development. Initially contracts will be awarded for phases 1 and 2 (Discovery and Alpha) with
decisions on Beta and live operation dependent on the result of those phases.
Digital Services Framework Agreement - RM1043
Document1
Page 11 of 29
Request for Proposal
Digital Services Framework Agreement – RM1043
It should be noted that while the Central IDAM services (Lot 3) have been divided into four component
services, these component services do not necessarily need to be implemented with separate
products/services; it is possible that more than one component can be implemented with the same product.
Additionally the strategic requirements are not intended to be definitive and complete final specifications, as
further analysis is required with individual CPP service providers to define the full set of business
requirements as plans are clarified. However, they are appropriate to provide direction to the programme and
its component projects.
Assumptions
In drawing up these requirements a number of assumptions have been made, in particular about the
timescales within which services will be required and available. These include that:
a.
Lot 1 a) (registration and authentication for magistrates) and Lot 3 (central IDAM Services) will be
required for services to go live between 3- 6 months from end of July 2014;
b.
Lot 1 b) (organisational access via Internet) and Lot 2 (public sector access) will be required for
services to go live between 6-9 months from end of July 2014;
c.
GDS IDA services for Citizen access are available now and that on-boarding of services (e.g. for “Plea
on-line PoL) can be achieved within 3-4 months of decision to use the GDS service;
d.
GDS are investigating services that may provide for organisational access and delegated authority
management. They have completed an Alpha with HMRC but no firm plans are in place for further
development at this stage. It is assumed that GDS will not be in a position to provide a service before
April 2015, and that an interim service for Common Platform users (e.g. law firms and defence) will
need to be put in place to meet immediate needs.
e.
The architecture for the Common Platform IDAM solution is agnostic about the number and type of
IDPs or federation hubs that may be used for access, providing they adopt a federated approach,
integrate using open standards and are able to integrate with external components using SAML 2.0.
f.
PSN service Hubs have been procured but access to services will depend on all public sector user
organisations (e.g. CPS, MoJ FITS etc.) meeting the PSN service connection standards (or other
appropriate standards for government service federation). While relevant organisations intend to
connect, no specific plans are in place to do that. The assumption is that an interim service for public
sector access will need to be in place for at least 1 year to 18 months.
CAPABILITIES AND ROLES
CAPABILITY
CUSTOMER’S REQUIRED OUTCOME
The technical architect capability is required to work with developers,
customer solution architect, customer information security architect and
front-end designers to:

Provide hands-on technical leadership in the development or
configuration, operation and ongoing improvement of the IDAM
solution components.

Work with the solution architect to identify technical options, design
patterns for the IDAM solution and inform.

Provide a technical solution which meets the requirements of the
IDAM solution.
Software Engineering and
Ongoing Support
Digital Services Framework Agreement - RM1043
Document1
Page 12 of 29
Request for Proposal
Digital Services Framework Agreement – RM1043

Convey technical design effectively to the solution architect and
provide on-going technical support to the development team.

Provide high and low level design for the chosen software to meet
the requirements of the IDAM solution.

Provide guidance to the development team following the GDS
Service Design Manual.
The developer(s) capability is required to work on the software development
or configuration and testing, liaise with the designer, technical architect,
business analysts and subject matter experts to:

Liaise with the technical architect to turn the technical design into a
product solution that fulfills the IDAM requirements.

Provide fully tested, reviewed, production level code.

Follow any design patterns and best practice guides as provided by
the technical architect and those dictated by the requirements.

Deliver that code in the team’s configuration management systems.

Liaise with the supplier delivery manager to co-ordinate delivery of
releases for testing.

Provide an assurance role to validate what is produced and build in
quality from the start.
Estimate ongoing development work to facilitate planning for
upcoming sprints and be involved in the ongoing prioritisation of core
aspects of the service.
Work with the wider delivery teams and stakeholders to break
technical requirements down into appropriate pieces for integration.
Provide integration and provide support for integration testing to the
Identity Provider software and applications such as the Magistrate’s
Court Rota and Document Store.
Be able to deploy the solution using open sourced solutions.




The product manager capability is required to work with the business analyst
and subject matter expert to:
Product Development and
Service Design

Manage ownership of the product being delivered.

Manage guidance to testers for acceptance criteria of the delivered
product.

Manage acceptance that the delivered solution meets the IDAM
functional and non-functional requirements.

Manage acceptance that the delivered solution meets the front-end
and interaction design.

Manage acceptance that a high quality user experience for the end
to end solution of the IDAM solution has been achieved.
The delivery manager capability is required to work with the development
team, customer’s tester(s) and customer’s project manager to:
Agile Delivery Management

Can act as the Scrum master in daily standups.

Plan for sprints and retrospectives.

Remove any impediments that will hinder the development team
from delivering the solution.
Digital Services Framework Agreement - RM1043
Document1
Page 13 of 29
Request for Proposal
Digital Services Framework Agreement – RM1043

Ensure continuous delivery.

Help other product teams and stakeholders to understand the work
being done.

Work with the development team and customer tester(s) to schedule
in releases for testing of the IDAM components.

Work with the development team and customer tester(s) to schedule
in releases for integration testing.

Work with the development team and customer tester(s) to ensure
timely delivery of releases according the project manager’s plan.

Raise any risks to the customer project manager which will impact
delivery of the IDAM solution according to the project plan.
The designer capability is required to work with the solution architect, subject
matter expert, business analyst and developer(s) to:



Front-end Design and
Interaction Design



Deliver high quality user experiences through the IDAM solution’s
common interface.
Design the user experience in line with the GDS style guide (look,
feel, tone, brand etc.).
Challenge assumptions about the right way to do things, and work
effectively with subject matter experts and business analysts to find
the right solution.
Provide a responsive design, and reflect that accordingly in
approaching questions of user interaction.
Be comfortable working in an agile environment with rapidly
changing deadlines, workloads and goals.
Work with information security, technical and solutions architects
where necessary to understand how design choices support security
being built into the service.
PRICING MODEL
Customer’s preferred pricing model or models, for SOWs that may be awarded as a consequence of this
Further Competition, are shown in the following table:
PRICING MODEL
PROJECT PHASES
Time and materials
Discovery
Capped time and materials
Alpha (plus Beta and Live should we proceed to these
phases)
CUSTOMER LOCATIONS
Digital Services Framework Agreement - RM1043
Document1
Page 14 of 29
Request for Proposal
Digital Services Framework Agreement – RM1043
UK REGION
CUSTOMER LOCATIONS: CITIES OR TOWNS
London and South East of England
Rose Court, 2 Southwark Bridge, London SE1 9HS or
102 Petty France, London SW1H 9AJ
Digital Services Framework Agreement - RM1043
Document1
Page 15 of 29
Request for Proposal
Digital Services Framework Agreement – RM1043
TEST & DEVELOPMENT REQUIREMENTS
The IDAM solution will be hosted on the Common Platform. Environments will be created as required and
remote access will be provided. The IDAM project team and other Ministry of Justice staff will require access
to these environments as development progresses in order to support the applications.
Digital Services Framework Agreement - RM1043
Document1
Page 16 of 29
Request for Proposal
Digital Services Framework Agreement – RM1043
ADDENDUM A
CJS Common Platform
Programme IDAM Project Requirements: Lot
3: Central IDAM Services
Digital Services Framework Agreement - RM1043
Document1
Page 17 of 29
Request for Proposal
Digital Services Framework Agreement – RM1043
REQUIREMENTS FOR IDAM COMPONENTS
1.1
Requirements context
1.1.1
For each component, functional and non-functional requirements are presented for the strategic
solution and the interim solutions required in the short-to-medium term (next 12-18 months). The
MoSCoW method has been used to prioritise the requirements, with the following interpretation:
1. Must: these requirements must be satisfied for the solution to be successful;
2. Should: these are high-priority or critical requirements that should be included if possible,
but workarounds may be possible;
3. Could: these requirements are nice-to-have and would be worth including but are not
worth significant investment; it should be noted that these requirements may be
strategically very important but rated as “Could” for interim solutions where is as
assumed that they will be covered by other components of the programme;
4. Won’t: these requirements will not be implemented; requirements are only rated as
“Won’t” for interim solutions to emphasise their difference from strategic solutions.
1.1.2
Requirements for the Common Platform Point of Access Solution (Lot 3a)
1.1.2.1
The requirements for the Common Platform Point of Access solution for all user groups are
shown in Table 0-1.
ID
Requirement
Priority
Justification
Functional requirements
CF1
The Point of Access solution will
present an initial page to potential
users, which invites users to supply
credentials via an authorised IdP or
IDAM hub service.
Must
There will need to be a front door that
enables potential users to log on to
the system. Credentials will be
supplied via an external IdP. For GDS
IDA IdPs, communication will be via
the hub.
CF2
The Point of Access solution will
deny access to the Common
Platform to unauthorised users.
Must
Unauthorised users should not have
access to the system.
CF3
The Point of Access solution will
allow users to log in by supplying
appropriate credentials to an
approved Identity Provider (IdP).
Must
This is the primary purpose of the
Point of Access service.
CF4
The Point of Access solution will
provide a list of appropriate and
approved IdPs to users from which
to select.
Must
This functionality is required to ensure
usability of the system. The list will
need to be appropriate to the access
channel being used. It will include all
PSN authentication providers and any
non-IDA internet-facing IdPs.
CF5
The Point of Access solution will
Must
enable other services to provide
users with a list of appropriate and
approved IdPs from which to select.
Digital Services Framework Agreement - RM1043
Document1
For IDA, the list of approved IdPs will
be provided by the IDA hub. This
functionality is required to ensure
usability of the system.
Page 18 of 29
Request for Proposal
Digital Services Framework Agreement – RM1043
ID
CF6
Requirement
Priority
The Point of Access solution will
Must
allow users to select which IdP they
wish to use, either directly or via an
authorised hub service.
Justification
The solution must support multiple
IdPs, determined by type of user. The
list of IDA IdPs will be provided by the
IDA hub service. Other IdPs will
interact directly.
Integration and connectivity
CF8
The Point of Access solution will
integrate using open standards.
Must
The Common Platform architecture
involves a federated identification
approach. Open standards are
required in accordance with
Government and MoJ ICT policy.
CF9
The Point of Access solution will
be able to integrate with external
components using SAML 2.0.
Must
SAML 2.0 is the de-facto standard
for federated identity and is used in
nearly all implementations. It has
been adopted by the Cabinet Office
for the IDA and the PSN service
federated identity schemes.
CF10
The Point of Access solution will
be accessible via the Internet
Must
Users will be accessing Common
Platform applications via the internet.
CF11
The Point of Access will be
accessible via the PSN or GSI
Must
Users will be accessing Common
Platform applications via the GSI and
PSN, albeit through different
instances of the Point of Access.
CF12
The Point of Access solution will
be able to integrate with current
and future Common Platform
applications to enable authorised
users to securely log in to
Common Platform services using
their provided identity and
associated credentials.
Must
Allowing authorised users to log in to
applications is the primary purpose
of the solution.
CF13
The Point of Access Solution will
produce logs that can be passed to
an external Protective Monitoring
Service.
Must
This is required to enable Protective
Monitoring across the Common
Platform.
Non-functional requirements
Security
CN1
The Point of Access solution will be
accredited, or accreditable, to
include data that has an impact
level of OFFICIAL - SENSITIVE.
Must
The Common Point of Access solution
should not be handling any data
above OFFICIAL - SENSITIVE.
CN2
The Point of Access solution will
satisfy the PSN connectivity
requirements.
Must
This is required for integration with the
PSN service.
Digital Services Framework Agreement - RM1043
Document1
Page 19 of 29
Request for Proposal
Digital Services Framework Agreement – RM1043
ID
Requirement
Priority
Justification
CN3
The Point of Access solution will
satisfy the GDS IDA connectivity
requirements.
Must
This is required for integration with the
GDS IDA.
CN4
The Point of Access solution will
validate the authenticity of SAML
tokens received from external
parties by verifying that they have
been digitally signed by a trusted
source.
Must
The Common Point of Access
Solution will need to validate that
authentication assertions have been
made by trusted and authorised
services.
CN5
The Point of Access solution will be Must
able to receive structured data
(XML or JSON) and validate against
a known schema.
This is required to ensure that the
contents of the SAML tokens are
valid.
CN6
The solution will secure
Must
communications using an Extended
Validation (EV) certificate so that
users can verify that the service can
be trusted.
Users will need to be able to have
strong assurance in the identity of the
service so that they can be confident
in the security of the website.
CN7
The solution will be able to pass
Must
structured data (XML or JSON) from
a SAML token across a bridge.
This is required to meet Pan
Government Accreditor (PGA)
requirements.
CN8
The Point of Access solution will
produce logs that can be passed to
an external Protective Monitoring
Service.
Must
This is required to enable Protective
Monitoring across the Common
Platform.
CN9
The solution will timeout a user’s
session after a configurable period
of inactivity.
Must
This is required to prevent a user
accidentally leaving themselves
logged into the system.
The Point of Access solution will
support 45,000 Internet users
(including 25,000 Magistrates and
20,000 users within defence
organisations) and 15,000 Public
Sector users (mainly from HMCTS
and CPS), accessing the services
via GSI or PSN.
Must
This is based on known requirements
up to 2016. The exact quantification of
this requirement will need to be
determined subsequently, when the
full set of business requirements have
been identified.
Over time this component will need to
support the full set of Common
Platform users.
Capacity
CN12
Performance
Digital Services Framework Agreement - RM1043
Document1
Page 20 of 29
Request for Proposal
Digital Services Framework Agreement – RM1043
ID
Requirement
C13
Priority
Justification
The Point of Access solution will be Must
able to pass at least 6,000 matching
requests per minute to the CJS
Common Platform Matching
Service.
With a large number of potential users
it is expected that there will be a
number of concurrent authentication
requests. At peak times of day (based
on 10% of users authenticating at
peak times).
The exact quantification of this
requirement will need to be
determined subsequently, once the
full set of business requirements have
been identified.
The Point of Access solution will
achieve an appropriate level of
availability.
Must
The exact quantification of this
requirement will need to be
determined subsequently, once the
full set of business requirements have
been identified.
This component will have a high
availability as it is required for all
access to the Common Platform.
Please provide options for standard
service levels
Availability
CN14
Disaster recovery
CN15
Should the Point of Access solution
fail, it will be restored within an
acceptable time.
Must
The exact quantification of this
requirement will need to be
determined subsequently, once the
full set of business requirements have
been identified. Please provide
options for standard service levels
CN16
Should the Point of Access solution
fail, no data shall be lost that has
been stored on the system more
than an acceptable time.
Must
The exact quantification of this
requirement will need to be
determined subsequently, once the
full set of business requirements have
been identified. Please provide
options for standard service levels
Table 0-1: Requirements for the Common Point of Access Solution
1.1.3
Requirements for the Common Platform Matching Service
1.1.3.1
The Common Platform will require a Matching Service. The requirements for the Common
Platform Matching Service are shown in Table 0-2.
1.1.3.2
To avoid duplicating requirements it should be noted that in addition to functional requirements
listed below for the matching service, the solution shall provide the appropriate Capacity,
Performance, Availability and Disaster Recovery (DR) service capabilities (CN12-16) indicated
above for Lot 3a: Common Point of Access.
ID
Requirement
Digital Services Framework Agreement - RM1043
Document1
Priority Justification
Page 21 of 29
Request for Proposal
Digital Services Framework Agreement – RM1043
ID
Requirement
Priority Justification
Functional requirements
MF1
The CP Matching Service shall
receive incoming access
requests, match against
authorised users and issue an
appropriate token to assert the
Common Platform applications
that they have access to.
Must
This is the primary purpose of the
matching service.
MF2
The CP Matching Service will
identify which applications a
Common Platform user has
access to.
Must
This forms part of the access
control solution for the Common
Platform. Individual applications will
maintain their own RBAC for
application-specific functionality.
MF3
The CP Matching Service will
support multiple identities for
any CP user.
Must
Individual users may have multiple
identities from different identity
providers (e.g. at different
strengths) but will need to access a
common account.
MF4
The CP Matching Service will
support multiple access
channels for any CP user.
Must
Individual users may have multiple
identities from different identity
providers with different access
channels (e.g. via the PSN and via
the Internet).
MF5
The CP Matching Service will
access information from the
Directory Service.
Must
The Directory Service will be the
single master source of CP
account information.
MF6
The CP Matching Service will
define a single Common
Platform Unique Identifier
(CPUI) for each user.
Must
The CPUI will form the global
identifier for users across the
Common Platform applications.
MF7
The CP Matching Service will be Must
able to match using the GDS
IDA profiles.
Exploiting the GDS IDA scheme
will facilitate the delivery of the
Common Platform objectives.
MF8
The CP Matching Service will be Must
able to match using the PSN
service profiles.
Exploiting the PSN service scheme
will facilitate the delivery of the
Common Platform objectives.
MF9
The CP Matching Service will be Must
configurable so that the set of
attributes to be provided by
Identity Providers when
identifying individuals can be
defined.
It will be necessary to ensure that
identified individuals can be
matched to ensure that they are
authorised. There should be some
flexibility in this implementation to
facilitate additional identity
providers.
MF10
The IDA Matching Service
component (of the overall CP
Matching Service) will be
separate from the Point of
Access Service.
This is required for privacy reasons
by the GDS IDA requirements.
Digital Services Framework Agreement - RM1043
Document1
Must
Page 22 of 29
Request for Proposal
Digital Services Framework Agreement – RM1043
ID
Requirement
Priority Justification
MF11
The IDA and PSN service
Could
components of the CP Matching
Service will be able to be shared
across multiple services within
Government Departments
including the Ministry of Justice
and the Crown Prosecution
Service.
This is not a specific Common
Platform requirement, but re-use
within the department would
enable greater value-for-money to
be achieved by the Ministry of
Justice and CPS from the
investment.
Integration and connectivity
MF12
The CP Matching Service will
integrate using open standards.
Must
The Common Platform architecture
involves a federated identification
approach. Open standards are
required in accordance with
Government and MoJ ICT policy.
MF13
The CP Matching Service will be Must
able to integrate with external
components using SAML 2.0.
SAML 2.0 is the de-facto standard
for federated identity and is used in
nearly all implementations. It has
been adopted by the Cabinet
Office for both the IDA and PSN
service federated identity schemes.
MF14
The CP Matching Service will be Must
able to receive structured data
(XML or JSON) and validate
against a known schema.
This is required to meet Pan
Government Accreditor (PGA)
requirements
MF15
The CP Matching Service will
Must
produce logs that can be
passed to an external Protective
Monitoring Service.
This is required to enable
Protective Monitoring across the
Common Platform.
Non-functional requirements
Security
MN1
The CP Matching Service will be Must
accredited, or accreditable, to
include data that has an impact
level of OFFICIAL - SENSITIVE.
The CP Matching Service
potentially enables full access to
the Common Platform and will
need to be protected to a high level
to ensure the security of the overall
system.
MN2
The CP Matching Service will
Must
validate requests received to
assure trust between matching
service and the point of access.
The matching service needs to be
protected to a high level to ensure
the security of the overall system.
MN3
The CP Matching Service will
Must
maintain data confidentiality and
integrity.
The matching service should not
be vulnerable to data being
infected or changed by
unauthorised sources.
Digital Services Framework Agreement - RM1043
Document1
Page 23 of 29
Request for Proposal
Digital Services Framework Agreement – RM1043
ID
Requirement
Priority Justification
MN4
The CP Matching Service will be Must
protected but accessible from
the internet.
The service must be protected from
unauthorised access from the
internet to preserve integrity of
data but must enable
communication with the IDA Hub.
MN5
The CP Matching Service will
satisfy the PSN connectivity
requirements.
Must
This is required for integration with
the PSN service.
MN6
The CP Matching Service will
Must
satisfy the GDS IDA connectivity
requirements.
This is required for integration with
the GDS IDA.
Capacity, Performance, Availability and DR – see CN 12-16
Table 0-2: Requirements for the Common Platform Matching Service
1.1.4
Requirements for the Common Platform Directory Service
1.1.4.1
The Common Platform will require a Directory Service. The requirements for the Common
Platform Directory Service are shown in Table 0-3.
1.1.4.2
To avoid duplicating requirements it should be noted that in addition to functional requirements
listed below for the Directory service, the solution shall provide the appropriate Capacity,
Performance, Availability and Disaster Recovery (DR) service capabilities (CN12-16) indicated
above for Lots 3a and 3b.
ID
Requirement
Priority Justification
Functional requirements
DF1
All information used by the
Access, Account, Matching and
Enrolment services will be
stored in the Directory Service.
Must
A single repository is required to
ensure cohesion of the overall
programme architecture.
DF2
The Directory Service will
support a single account for
each user, regardless of the
number of access channels /
identities of that user.
Must
This is required both for
accountability and usability
purposes.
DF3
The Directory Service will
Must
produce logs that can be
passed to an external Protective
Monitoring Service.
Digital Services Framework Agreement - RM1043
Document1
This is required to enable
Protective Monitoring across the
Common Platform.
Page 24 of 29
Request for Proposal
Digital Services Framework Agreement – RM1043
Integration and connectivity
DF3
The Directory Service will
Must
integrate using open standards.
The Common Platform
architecture involves a
federated identification
approach. Open standards are
required in accordance with
Government and MoJ ICT
policy.
DF4
The Directory Service will
support the synchronisation of
the Directory information with
Common Platform applications,
including the CPUI.
It will necessary to share the
common user account
information with applications to
ensure that they are also able to
access it. Where central
directory information is held by
applications, they shall be readonly copies that are updated
from the master central
directory.
DF5
The Directory Service will
Must
provide a capability to enable
users within Common Platform
applications to request changes
to the directory information and
to mediate any updates.
Should
Applications may need to
initiate changes to central
directory information. This
needs to be mediated by a
central component to ensure
consistency. This could be
achieved by redirecting access
to a central user interface, or by
providing appropriate system
interfaces.
Non-functional requirements
Security
DN1
The CP Directory Service will be Must
accredited, or accreditable, to
include data that has an impact
level of OFFICIAL - SENSITIVE.
The CP Directory potentially
enables full access to the
Common Platform and will need
to be protected to a high level to
ensure the security of the
overall system.
DN2
The CP Directory Service will
validate requests received to
assure trust between matching
service and the Directory.
The Directory needs to be
protected to a high level to
ensure the security of the
overall system.
DN3
The CP Directory Service will
Must
maintain data confidentiality and
integrity.
Digital Services Framework Agreement - RM1043
Document1
Must
The Directory should not be
vulnerable to data being
infected or changed by
unauthorised sources.
Page 25 of 29
Request for Proposal
Digital Services Framework Agreement – RM1043
DN4
The CP Directory Service will
not be accessible directly from
the internet,
Must
The Directory must be protected
from unauthorised access from
the internet to preserve integrity
of data. There is no need to
directly access the Directory
from the internet and all access
should be mediated via other
components.
DN5
The CP Directory service will
allow secure management
access only for appropriately
authorised super users.
Must
The Directory must be protected
from unauthorised to preserve
integrity of data.
DN6
The CP Directory service will
provide secure storage with
encryption at rest.
Must
The CP Directory will contain
sensitive personal information
and will need to be protected to
a high level to ensure the
security of the overall system.
Capacity, Performance, availability and Disaster Recovery – see CN 12-16
Table 0-3: Requirements for the Common Platform Directory Service
1.1.5
Requirements for the Common Platform Enrolment and User Account Management
Service
1.1.5.1
The Common Platform will require an Enrolment and User Account Management Service. The
requirements for the Common Platform Enrolment and User Account Management Service are
shown in Table 0-4.
1.1.5.2
To avoid duplicating requirements it should be noted that in addition to functional requirements
listed below for the Directory service, the solution shall the appropriate Capacity, Performance,
Availability and Disaster Recovery (DR) service capabilities (CN12-16) indicated above for Lots
3a, 3b and 3c.
ID
Requirement
Priority Justification
Functional requirements
EF1
The Enrolment and User
Account Management solution
will enable applications and
other technical components to
request account information
relating to individuals (e.g.
through a web services
interface).
EF2
The Enrolment and User
Must
Account Management solution
will only provide information that
an application is authorised to
receive.
Digital Services Framework Agreement - RM1043
Document1
Must
Applications will need access to
information maintained by the
Enrolment and User Account
Management solution.
Applications should only be granted
access to information where there is
a business need – for example
applications should only be given
information regarding Common
Platform users that have been
enrolled with that application.
Page 26 of 29
Request for Proposal
Digital Services Framework Agreement – RM1043
EF3
The Enrolment and User
Account Management solution
will enable users to view their
own account attributes.
Must
Users will need to be able to view
account information so that they can
check that it is correct.
EF4
The Enrolment and User
Account Management solution
will enable users to modify
certain account attributes.
Must
The user will need to be able to
change some account information,
such as preference information.
EF5
Users will only be able to view
their own information and not
that of other users.
Must
Users only need to view their own
information and privacy must be
maintained.
EF6
The Enrolment and User
Account Management solution
will enable administrators to
suspend/disable accounts.
Must
It will be necessary to disable
accounts if it is suspected that the
credentials have been compromised.
EF7
The Enrolment and User
Account Management solution
will enable administrators to
unlock/re-enable accounts.
Must
It will be necessary to enable
accounts that have been locked or
suspended once the reason for
suspension has been resolved.
EF8
The Enrolment and User
Must
Account Management solution
will enable administrators to add
accounts.
It will be necessary to add accounts
for new users.
EF9
The Enrolment and User
Account Management solution
will enable administrators to
delete accounts.
Must
It will be necessary to delete
accounts when they are no longer
required.
EF10
The Enrolment and User
Account Management solution
will enable administrators to
modify account information.
Must
Maintenance of account information
will be required.
EF11
The Enrolment and User
Account Management Service
will access and store
information in the Directory
Service.
Must
The Directory Service will be the
single master source of CP account
information.
Integration and connectivity
EF12
The Enrolment and User
Account Management Service
will integrate using open
standards.
Must
The Common Platform architecture
involves a federated identification
approach. Open standards are
required in accordance with
Government and MoJ ICT policy.
EF13
The Enrolment and User
Account Management Service
will be accessible over the
internet for administrative
functions by appropriately
authorised administrators over
enhanced secure access.
Must
Administrative Super Users will need
to securely access the enrolment
and account management service
over the internet for administrative
purposes.
Digital Services Framework Agreement - RM1043
Document1
Page 27 of 29
Request for Proposal
Digital Services Framework Agreement – RM1043
EF14
The Enrolment and User
Account Management Service
will be accessible over the GSI.
Must
Administrative super users will be
accessing enrolment and account
management services via the GSI.
EF15
The Enrolment and User
Account Management Service
will be accessible over the PSN
with IPED (IL3).
Must
Administrative super users will be
accessing via the PSN (Previously
IL3).
EF16
The solution shall provide
functionality to support the
enrolment of authorised CP
users.
Must
It will be necessary to enrol further
users for Common Platform
applications. This requirement will
need to be expanded once further
business requirements have been
identified.
EF17
The Enrolment Service shall
Should
support the rapid provisioning of
users.
There are likely business
requirements for new users to gain
access to the Common Platform very
quickly (e.g. minutes rather than
hours/days), such as a duty solicitor
or barrister. While there are a
number of potential technical
solutions to this issue, rapid
provisioning of users will ensure that
accountability is maintained.
EF18
The CP Enrolment Service will Must
produce logs that can be
passed to an external Protective
Monitoring Service.
This is required to enable Protective
Monitoring across the Common
Platform.
Non-functional requirements
Security
EN1
The Enrolment and User
Must
Account Management Service
will be accredited, or
accreditable, to include data that
has an impact level of
OFFICIAL - SENSITIVE.
The Enrolment and User Account
Management potentially enables full
access to the Common Platform and
will need to be protected to a high
level to ensure the security of the
overall system.
EN2
The Enrolment and User
Account Management Service
will support appropriate
authentication measures.
Must
The Common Platform will hold
sensitive personal data and it is
important that it is only provided to
authenticated requestors. The
strength of authentication will
depend on the level of trust in the
environment from which it is being
requested.
EN3
The Enrolment and User
Account Management Service
will support appropriate
confidentiality measures.
Must
The Common Platform will hold
sensitive personal data and it is
important that it is provided securely.
The strength of authentication will
depend on the level of trust in the
environment from which it is being
requested.
Digital Services Framework Agreement - RM1043
Document1
Page 28 of 29
Request for Proposal
Digital Services Framework Agreement – RM1043
Capacity, Performance, Availability and Disaster Recovery – see CN 12-16
Table 0-4: Requirements for the Common Platform Enrolment and User Account Management
Service
Digital Services Framework Agreement - RM1043
Document1
Page 29 of 29