Federal Health Architecture

normalpetsSoftware and s/w Development

Nov 4, 2013 (4 years and 8 days ago)

141 views



Federal Health Architecture

Representational State Transfer (REST)
ful

Health Exchange (RHEX) Pilot


OpenID Connect

Pr
ofile

July
27
, 2012


ii










This page intentionally left blank.


iii

Abstract

The OpenID Connect Profile for Security defines the Representational State Transfer
(REST)ful Health Exchange (RHEx) Pilot implementation of the OpenID Connect protocol.
As such, this profile docu
ments the implemented subset of points of departure from and
interpretation of the OpenID Foundation OpenID Connect v1.0 specification framework.
These points of departure are referred to as extensibility points. Publication of the RHEx
Pilot OpenID Conn
ect Profile is intended to capture how the RHEx Pilot is
intended

to aid
interoperability.




iv

Revision Control

Revision #

Date

POC

Brief Description


v1.0

2
7
-
July
-
2012

Patricia
Dunn King

RHEx Pilot, Draft OpenID Connect Profile
baseline







































































v

Table of Contents

Introduction

................................
................................
................................
................................
............................

1

Background

................................
................................
................................
................................
.........................

1

Purpose

................................
................................
................................
................................
................................

1

Intended Audience

................................
................................
................................
................................
...........

2

OpenID Connect and Related Standards

................................
................................
................................
.

2

Community Participation

................................
................................
................................
..............................

3

Notational C
onventions

................................
................................
................................
................................
.

3

Soliciting Public Comment

................................
................................
................................
............................

3

Profile Notation & Conformance

................................
................................
................................
.....................

5

Notation Conventions

................................
................................
................................
................................
.....

5

Conformance

................................
................................
................................
................................
......................

5

OpenID Connect

................................
................................
................................
................................
.....................

7

RHEx OpenID Connect Technical Implementation

................................
................................
..................

9

RHEx Conformance Tables

................................
................................
................................
.............................

11

Extensibility Points in OpenID Connect Messages

................................
................................
...........

11

Extensibility Points in OpenID Connect Standard

................................
................................
............

12

Acronyms

................................
................................
................................
................................
..............................

14



vi

Table

of Figures

Figure 1.
OpenID Connect Specification Framework

................................
................................
................

7


Figure 2
.
RHEx Use of OpenID Connect

................................
................................
................................
......

10









1

Introduction

RESTful Health Exchange (RHEx) is a fiscal year (FY) 2012, open
-
source pro
ject to
develop
a prototype of a Representational State Transfer (REST) architecture
-
based data exchange
to explore a World Wide Web model of health information exchange
. Sponsored by the
Federal Health Architecture (FHA) program, the RHEx project
adopted
many of the goals
identified in the Health Information Technology (HIT) Standards Committee, Nationwide
Health Information Network (NwHIN) Power Team recommendations.
1

REST, together
with other technologies, enables such a World Wide Web health informatio
n exchange. The
NwHIN Power Team draft recommendations identified REST as a widely accepted,
complementary technology to several important health information exchange
specifications.

Background

An implementation of a RESTful architecture prototype

will in
form the
NwHIN
specification development process, exploring

the NwHIN Power Team recommendation to
develop a specification for a RESTful exchange of health data.
The

RHEX
Team

is
developing pilots using open standards such as OpenID Connect for authentica
tion and
OAuth 2.0 for authorization, as well as the Health Level 7 International (HL7) emergent
specifications for defining the exchange of health data

to effectively prototype a REST
implementation for health information exchange.
Ultimately, this
proto
type

is intended to
ensure that health information exchange scales to the national level,
provide
s

strong,
scalable security at low cost
, ensures interoperability,
increase
s

NwHIN adoption
,

and
foster
s

innovation.

Purpose

The purpose of this
OpenID Conne
ct

profile is to document the RHEx implementation of
extensibility points and use of optional components in
pursuit of

interoperability among
systems exchanging health data

in a high
-
assurance environment and deployment
.
Other
environments and deployments

may use different conformance profiles based on the same
underlying technology.
This deliverable document profiles the RESTful Health Exchange
(RHEx) Pilot implementation of Open ID Connect (Implementers’ Draft, dated 23 June
2012), including both OpenID
Connect Standard 1.0 (Draft 12) and OpenID Connect
Messages 1.0 (Draft 12). Together, these companion specifications form a
standardized
identity and authentication layer on top of
the OAuth 2.0 protocol

for RHEx
.

And, thus, the
RHEx OpenID Connect profi
le inherits all constraints and extensions in the RHEx OAuth2.0
profile, except as specifically noted.




1

HIT Standards Committee, NwHIN Power Team Briefing
Updated Scores, Grids and DRAFT Recommendations
,
16 Sep 201
1, pages 4
-
5, 17.


2

Intended Audience

All documentation developed for this task related to the RHEx pilots and the RHEx
Implementation Profile will inform future implementa
tions of a
RESTful architecture
-
based
data exchange enabling a World Wide Web model of health information exchange
.
As such,
this RHEx Pilot OpenID Connect Security Profile documentation is intended to be useful to
both software developers and Health poli
cy makers.
The

RHEX T
eam

will publish the
documentation and open source software for the pilots on the RHEx wiki which is hosted as
an “affiliated project” on the Health and Human Services (HHS),
Office of the National
Coordinator for Health Information T
echnology (ONC)
,

Standards & Interoperability (S & I)
Framework wiki

and the
Github social coding repository

to foster broad participation in
the developmen
t of RESTful exchanges of health information.

OpenID Connect and
Related Standards

The purpose of this OpenID Connect security implementation profile is to document the
RHEx implementation of extensibility points and use of optional components in an eff
ort to
support interoperability among systems exchanging health data. Documenting the RHEx
implementation is particularly important because the specification offers many
extensibility points and optional implementation details.

Two

OpenID Connect
-
related

draft standards

used by the RHEx pilots
, as well as other
related standards, are referenced below. Each reference includes a unique tag for each
document to enable subsequent identification throughout this profile
.


OpenID Connect Standard 1.0
, Draft 12,

OpenID Foundation, 23 June 2012, Tag [OIDC
Standard];


OpenID Connect Messages 1.0, Draft 12, OpenID Foundation, 23 June 2012, Tag [OIDC
Messages];


OAuth 2.0 Authorization Framework
, IETF OAuth Working Group, work
-
in
-
progress (IETF
Internet
-
Draft
-
v2
-
30,
dated July 15, 2012), Tag [OAuth2.AF];

JSON Web Token (JWT)
, IETF OAuth Working Group, work
-
in
-
progress, (IETF Internet
-
Draft
-
02, dated July 16, 2012), Tag [OAuth2.JWT];

Javascript Object Signing and Encryption (
JOSE
)
, IETF JOSE Working Group, Multiple
Doc
uments, as follows:

JSON Web Algorithms (JWA)
, IETF Internet
-
Draft
-
04, July 16, 2012, Tag [
JOSE
.JWA];

JSON Web Encryption (JWE)
, IETF Internet
-
Draft
-
04, July 16, 2012, Tag [
JOSE
.JWE];


3


JSON Web Key (JWK)
, IETF Internet
-
Draft
-
04, July 16, 2012, Tag [
JOSE
.JW
K];

JSON Web Signature (JWS)
, IETF Internet
-
Draft
-
04, July 16, 2012, Tag [
JOSE
.JWS]

Hypertext Transfer Protocol (HTTP)
, v.1.1, IETF Network Working Group, RFC 2616, June
1999, Tag [HTTP];

Hypertext Transfer Protocol (HTTP) over TLS
, IETF Network Working Gr
oup, RFC 2818,
May, 2000, Tag [HTTPS];

Transport Layer Security (TLS),

v. 1.0, IETF Network Working Group, RFC 2246, January
1999, is the most common protocol used to encrypt data in transport. Although TLS v1.2 is
the most recent version of the TLS proto
col, TLS v1.0 is more widely deployed and its
security vulnerabilities better understood than more recent versions. OAuth 2.0 is
designed to interoperate with either version of TLS. Tag [TLS]

Community Participation

“The OpenID Foundation (OIDF) is an in
ternational non
-
profit organization of individuals
and companies committed to enabling, promoting and protecting OpenID technologies.
Formed in June 2007, the foundation serves as a public trust organization representing the
open community of developers,
vendors, and users. OIDF assists the community by
providing needed infrastructure and help in promoting and supporting expanded adoption
of OpenID. This entails managing intellectual property and brand marks as well as
fostering viral growth and global p
articipation in the proliferation of OpenID.”
2


Notational Conventions

Keywords identified in this Security Profile should be interpreted in concert with
Internet
Best Current Practices for the Internet Community
, IETF Network Working Group, RFC 2119,
Marc
h 1997.

Soliciting Public Comment

As an artifact of the RHEx “affiliated project”
hosted
on the ONC S&I Framework wiki, the
OAuth 2.0 Profile will be available for public comment. This open approach encourages
community dialog and cohesion around innovati
ve technical approaches to resolve health
information exchange challenges. Such an approach moves the community forward in
concert with The White House strategy for digital government in the 21
st

century.

3





2

http://openid.net/foundation/

[Website accessed: 29 May 2012]

3

Presidential Memorandum,
Building a 21st Century Digital Government
, The White House, Office of the Press
Secretary,
23 May 2012
, [Accessed on 25 July 2012].


4












This page intentionally left blank.

5

Profile Notation & Conformance

Test and evaluation activities leading to verification and conformance are enhanced by an
unambiguous specification of requirements. Clearly stated and defined specification
requirements’ notation is the basis of such veri
fication and conformance. For ease of
specification interpretation during implementation, the sections presented below
correspond to the representation of requirements in the
RHEx Interoperability Test
Framework
. The
RHEx Interoperability Test Framework

software is also available on the
RHEx Project Github social coding repository
.

Notation Conventions
4

The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED
", "MAY", and "OPTIONAL" in this document are to be
interpreted as described in RFC2119. Normative statements of requirements in the Profile
(i.e., those impacting conformance, as outlined in "Conformance Requirements") are
presented in the following mann
er:

<RnnnnStatement text here>

where "nnnn" is replaced by a number that is unique among the requirements in the
Profile, thereby forming a unique requirement identifier. Requirement identifiers can be
considered to be namespace qualified, in such a way a
s to be compatible with QNames from
Namespaces in XML. If there is no explicit namespace prefix on a requirement's identifier
(e.g., "R9999" as opposed to "
[
o
idc
]:R9999"), it should be interpreted as being in the
namespace identified by the conformance UR
I of the document section it occurs in. If it is
qualified, the prefix should be interpreted according to the namespace mappings in effect,
as documented below.

Conformance

“Conformance” discussed in this
Profile

should be interpreted in concert with the
“conformance” definitions and uses specified in
Web Services Interoperability Organization
(WS
-
I), Basic Profile Version 1.1, Final Material © 2002
-
2006
, 2006
-
04
-
10.

5



In summary, “Conformance to the Profile is defined by adherence to the set of
require
ments defined for a specific target, within the scope of the Profile.”
6

Further,



4

Drawn substantially and directly from
Web Services Interoperability Organization (WS
-
I), Basic Profile
Version 1.1, Final Material © 2002
-
2006
, 2006
-
04
-
10, Section 1.4 [Accessed on 7/17/2012:
http://www.ws
-
i.org/Profiles/BasicProfile
-
1.1.html#conventions
].

5

The content of Section 2.0 is drawn substantially and directly from
Web Services

Interoperability
Organization (WS
-
I), Basic Profile Version 1.1, Final Material © 2002
-
2006
, 2006
-
04
-
10, pp. 9
-
11 [Accessed on
7/17/2012:
http://www.ws
-
i.org/Profiles/BasicProfile
-
1.1.html#conventions
].


6

“Claims of conformance to the Profile can be made…when the applicable Profile
requirements associated with listed targets have been met.”
7










6

Ibid
, p. 9.

7

Ibid
, p. 11
.



7

OpenID Connect

All OpenID Conne
ct references in this profile are attributable to the OpenID Foundation
(OIDF) as constructive source material. The OpenID Connect specification framework is
copyrighted by OIDF ©
201
2
.


OpenID Connect is composed of several lightweight specifications as
well as underpinning

protocols depicted in Figure
1.



Figure
1
.
OpenID Connect Specification Framework


OpenID Connect is a suite of lightweight specifications that provide a
framework for identity interactions via RESTful
APIs. The simplest
deployment of OpenID Connect allows for clients of all types including
browser
-
based, mobile, and java

script clients, to request and receive
information about identities and currently authenticated sessions. The
specification suite is

extensible, allowing participants to optionally also
support encryption of identity data, discovery of the OpenID Provider, and
advanced session management, including logout.
[

]
OpenID Connect
performs many of the same tasks as OpenID 2.0, but does so in
a way that is
API
-
friendly. OpenID Connect can also be extended to include more robust
mechanisms for signing and encryption. Integration of OAuth 1.0a and

8

OpenID 2.0 required an extension (called the OpenID/OAuth hybrid); in
OpenID Connect, OAuth 2.0 ca
pability is built into the protocol itself.
8



8

http://openid.net/connect/

[Accessed: 18 July 2012]


9

RHEx OpenID Connect Technical Implementation

OpenID Provides a way for one user to log into another, remote system without a
username/password provisioned at that system and without a certificate from a central
trusted authority.

Figure 2 illustrates the RHEx use of OpenID Connect to enable Health
information exchange.



Figure
2
.
RHEx Use of

OpenID Connect




10










This page intentionally left blank.


11

RHEx Conformance Tables

Amp
lifying information related to requirements for extensibility points conformance is
presented in the Conformanc
e Tables. Conformance Tables 1 and
2 outline the RHEx Pilot
constraints of the OpenID Connect Messages specification for both the client and the

server
in
teraction; Conformance Tables 3 and
4 outline the RHEx Pilot implementation of the
OpenID Connect Standard specification for both client and server interaction.

Extensibility Points in OpenID Connect Messages


Requirement
Number

Conformance
Req
uirement
Level

Specification
Reference

RHEx Implementation

R3
001

MUST

[OIDC Messages]
Section 4.2

Client
REQUIRED to

be registered with
jwk_url signing keys

R3
00
2

MUST

[OIDC Messages]

Section 4.2

Client
REQUIRED to
support jwk formats
for Server

R3
00
3

MUST

[OIDC Messages]
Section 4.1

Client
REQUIRED to
be registered with
signing
algorithms for all end
points

R3
00
4

MUST

[OIDC Messages]
Section 4.1

Client and Servers
REQUIRED to
support
all default algorithms

R3
00
5

MUST

[OIDC Messages]

Section 4.3

C
lients and Servers
REQUIRED to
support
RS256 for Asymmetric Signatures and
HS256 for Symmetric Signatures

R3
00
6

MUST

[OIDC Messages]
Section 4.4

Clients and Servers
REQUIRED to
support
Asymmetric RSA Encryption

R3
00
7

MUST

[OIDC Messages]
Section 9 (Def
ault to
OAuth 2.0)

Client
REQUIRED to
register at least 1
redirect_uri


R300
8

MUST NOT

[OIDC Messages]
Section 9 (Default to
OAuth 2.0)

Client redirect_uris
MUST NOT

use HTTP
on a remote server.


R30
09

MUST

[OIDC Messages]
Section 9 (Default to
OAuth 2.0
)

Server
REQUIRED to
validate client
redirect_uris as using HTTPS protocol

for
a remote server.

Table
1

. OpenID Connect Messages Client Interaction


Requirement
Number

Conformance
Requirement
Level

Specification
Reference

R
HEx Implementation

R3
01
0

MUST

[OIDC Messages]
Section 4.2

Server
REQUIRED to

support jwk formats
for Client keys


12

Table
2

. OpenID Connect Messages Server Interaction

Extensibility Points in OpenID Connect
Standard

Table
3
outlines the RHEx implementation of OpenID Connect
Standard

specification
for
Client interaction; Table
4

outlines the RHEx implementation of OpenID Connect
Standard
specification for Server Interaction.


Requirement
Number

Conformance
Requirement
Level

Sp
ecification
Reference

RHEx Implementation

R3
01
1

MUST

[OIDC Standard]
Section 2.2
.2


Client REQUIRED to
use Authorization
Code Flow

to initiate request.


R3
01
2

MUST

[OIDC Standard]

Section 2.3.1

response_type
REQUIRED to

be code or

code id_token
.

R3
01
3

MUST


[OIDC Standard]

Section 2.3.1

Client

REQUIRED to
provide the
nonce

parameter
.

R3
01
4

MUST


[OIDC Standard]

Section 2.3.1

Servers
REQUIRED to
Support Signed
Request Objects
.

R3
01
5

MUST

[OIDC Standard]

Section 2.3.1

When a client provides a Request Ob
ject
as part of the authorization request the
Request Object
REQUIRED to
be signed
.

R3
01
6

MUST

[OIDC Messages]
Section 3.1.1

Client Authentication
REQUIRED to
be
private_key_jwt
.

Table
3

. OpenID Connect Standard Client Inte
raction



Requirement

Number

Conformance
Requirement
Level

Specification
Reference

RHEx Implementation

R3
01
7

MUST

[OIDC Standard]
Section 3.0

Authorization Server
REQUIRED to

sign
the id_token
.

R3
01
8

MUST

[OIDC Standard]
Section 3.
1.
2

Access tokens
REQUI
RED to

expire
within 5 minutes
.

R3
0
19

MUST

[OIDC Standard]
Section 3.2.1

Refresh tokens
REQUIRED to

expire
within 30 minutes
.


R3
02
0

MUST

[OIDC
Messages
]
Section 4.2

Response
REQUIRED to

be a signed
JWT
.

Table
4
.
OpenID Con
nect Standard
Server

Interaction



13












This page intentionally left blank.

14

Acronyms


FHA




Federal Health Architecture

FY




Fiscal Year


HIT




Health Information Technology

HITSP




Healthcare Information Technology Standards Panel

HL7




Health

Level 7 International

HTTP




Hyper Text Transfer Protocol

HTTPS




Hyper Text Transfer Protocol
[Over TLS]
Secure


JOSE




JSON Object Signing and Encryption

JSON




Java Script Object Notation

JWA




JSON Web Algorithms

JWK




JSON Web Key

JWS




JSON W
eb Signature

JWT




JSON Web Token


NwHIN



Nationwide Health Information Network


ONC

Office of the National Coordinator for Health Information
Technology

REST




Representational State Transfer

RHEx




RESTful Health Exchange


TLS




Transport Layer Secu
rity


URI




Uniform Resource Identifier

URL




Uniform Resource Locator

WWW




World Wide Web


15













This page intentionally left blank.