Presentation is loading. Please wait.

Presentation is loading. Please wait.

wiki.siframework.org/RHEx

Similar presentations


Presentation on theme: "wiki.siframework.org/RHEx"— Presentation transcript:

0 Meeting Etiquette Please announce your name each time prior to making comments or suggestions during the call Remember: If you are not speaking keep your phone on mute Do not put your phone on hold – if you need to take a call, hang up and dial in again when finished with your other call Hold = Elevator Music = very frustrated speakers and participants This meeting, like all of our meetings, is being recorded Another reason to keep your phone on mute when not speaking! Feel free to use the “Chat” or “Q&A” feature for questions or comments, especially if you have a bad phone connection or background noise in your environment From S&I Framework to Participants: Hi everyone: remember to keep your phone on mute  NOTE: This meeting is being recorded and will be posted on the Wiki page after the meeting

1 RESTful Health Exchange (RHEx) Security Overview WebEx #3 July 26, 2012
wiki.siframework.org/RHEx Powering Secure, Web-Based Health Data Exchange DRAFT—for discussion purposes only

2 Overview RHEx and the Security Challenge The RHEx Access Model
The problems RHEx aims to solve RHEx and Document Linking – the Filing Cabinet analogy The RHEx Access Model The basic model Extensibility The underlying standards: OAuth and OpenID Connect RHEx Support for Services RHEx support for NIST Levels of Assurance Summary

3 Orientation - What is RHEx?
An open source, exploratory project to apply proven web technologies to demonstrate a simple, secure, and standards-based health information exchange Sponsored by the Federal Health Architecture (FHA) program Called RESTful Health Exchange (RHEx) A Fiscal Year 2012 project demonstrating RESTful health information exchange in two phases Phase I: Security Approach (April-July 2012) Phase II: Content Approach (July-September 2012) Powering Secure, Web-Based Health Data Exchange wiki.siframework.org/RHEx

4 What Are the Elements of RHEx Security?
IDENTITY Who am I? IDENTIFIERS How is that identity represented? AUTHENTICATION How can I prove who I am? AUTHORIZATION What can I do when I've proved who I am? Something you know Something you have Something unique to you

5 What Are the Basic Problems RHEx is Exploring?
Data needs to be made available only to authorized parties Data needs to be accessible to services via API calls and end users within a browser Security protocols need to work with HTTP and REST Security needs to be easy for application providers to deploy on their systems Privacy is enforced by implementation of security controls People need to be given notice about data access

6 RHEx Security Take-away Points
RHEx approach is secure Uses same trusted tools used by high volume, secure systems to move money and exchange other sensitive information Secure Transport: all transactions over Transport Layer Security protected HTTP Exchanged tokens verified by trusted 3rd party RHEx security is interoperable Integrates with JSON, XML, HTML, etc. Designed to support NIST Level of Assurance up to 3 (Identity Provider dependent) Harmonizes with existing NwHIN standards RHEx security is scalable Documents contain separable links to information – each uniquely securable Allows security and privacy to be applied atomically

7 RHEx as a RESTful Approach: Document Linking
Documents contain HTTP links to information Clients (web browsers) fetch them separately Arbitrary granularity with a well-designed API Allows security and privacy to be applied atomically Each request can be to a different security domain Each request can have its own authentication parameters Supports privacy and security practices of existing deployments Availability of information can be hidden where appropriate Presence of a URL in one document does not indicate presence of information at that URL Knowledge of a URL does not automatically grant permission to view content at that URL

8 A RHEx Mental-Model: Filing Cabinets
Historically, paper health records were separated Two physically distinct filing cabinets in different buildings held different parts of the records Traditional Electronic Health Record (EHR) approaches make one giant filing cabinet All records get pulled to a single digital filing cabinet and distributed from there RHEx approach allows digital separation Like having a file in one filing cabinet with a note stapled to it in the right place with the address of another filing cabinet If you want what’s in the other filing cabinet, you have to go to that cabinet to get it The other filing cabinet decides whether or not to let you in

9 Consider as a Model: The Paper-based System
Primary Care Specialist In paper based systems, each organization keeps its records in its own filing cabinet

10 Traditional EHR Approach in This Model
Data Gateway In a traditional EHR, everyone accesses data through the big digital filing cabinet in the sky, which has access to all member systems on your behalf.

11 The RHEx Approach in this Model
URL link to record Primary Care Specialist With RHEx approach, each organization keeps its own cabinet, but records can contain pointers to files that live in someone else’s cabinet.

12 OpenID Connect Use in the RHEx Model
OpenID provides a way for one user to log into another, remote system without having a username/password provisioned at that system, and without having a certificate from a central trusted authority. Primary Care Specialist OpenID Connect allows a user to use their account on one system to log in to a remote system in a verified way, without relying on a shared central authority.

13 OAuth Use in the RHEx Model
Primary Care Specialist OAuth allows the cabinets to be locked and controlled separately, but gives a way to issue limited-use keys to other parties.

14 The RHEx Access Model Start with a simple beginning Extend the model
Physical security works generally on a whitelist model: if you have a key, you can open the door Whitelist individuals and providers to drive auditing, access control, and granular authorization Extend the model Employ User Attributes for trust decisions – extend the simple whitelist model and allow for expansion Use Trust Frameworks to manage whitelist Integrate existing standards Implement basic model, data exchange in a Trust Framework, and accommodate extensibility using technologies that already exist, and which are extensively employed commercially Provide support for end users and for services

15 RHEx Access Model Simple Beginning
Whitelisting individuals Individual identities tagged as cleared to view a piece of information OpenID identifiers are like addresses Don’t have to be held in a common global repository Contain both individual and organizational components has access to record /patient1234/medications” Whitelist identity providers Accept identities from certain domains “anybody from pcp.com can get basic patient information like name, height, and weight”

16 RHEx Access Model Extend the Model
Attributes on users Attributes of a user can help us make access decisions Claimed attributes may be verified at a variety of identity or attribute providers “anybody with the attribute isAnOncologist from a trusted attribute provider can get at oncology records” Trust Frameworks How can you be sure that what another system says is true? Enforceable sets of business, legal, and technology rules National Strategy for Trusted Identity in Cyberspace (NSTIC) bases trust relationships on these Trust Frameworks

17 RHEx Access Model Extend the Model: Claims of User Attributes
All claims are extensible JSON-based schema Profile information Name, , phone Distributed claims URL to fetch more information Follows RESTful linking model { user_id: “12341”, name: “John Doe”, clinicalRole: “oncology”, oncology: “http://asco.org/userinfo/jdoe” }

18 RHEx Access Model Extend the Model: Extending Claims for Health Care
RHEx will extend the user attributes and claims with domain-specific information Claims need to be trustable We don’t want this self-asserted For example: Clinical role Organization that we trust claims “Dr. Joe is an Oncologist” Not all claims need to be held in a central store Not all claims need to be held at the IdP IdP points to attribute provider with a URL

19 RHEx Access Model Standards in Action
OAuth2 Token-based protocol for securing data APIs Internet Engineering Task Force (IETF) Draft standard OpenID Connect Distributed identity API Built on top of OAuth2 OpenID Foundation JSON Web Tokens Structured, signed token format, used by OpenID Connect HTTPS All transactions over Transport Layer Security protected HTTP Server certificates from trusted sources, no client certificates Most successful pattern of use on the web today

20 RHEx Access Model Nascent Standards Built on Experience
OpenID and OAuth spec authors and core implementers have years of deployment experience with: SAML OpenID 2.0, 1.0 OAuth 1.0 PKI Legacy protocols have shown limitations with use New protocols are needed to work effectively in today’s RESTful, AJAXy, mobile-friendly world wide web Take the best from all competitive technologies and apply it to a new world and new context OpenID Connect is the sum of this experience so far

21 The good thing about reinventing the wheel is that you can get a round one.
- Douglas Crockford

22 RHEx Access Model Standards in Action: OAuth and OpenID In Use By Industry
Built by a consortium with a lot at stake Trial by fire on the open internet

23 RHEx Access Model Services Authorization
In addition to end user support, RHEx System must allow direct service connections (machine-to-machine) Can’t count on user-held credentials being present Will provide a module to authorize services to access data on behalf of a user OAuth 2 Access Tokens can be issued for this case Token inherits subset of permissions of user or service that authorized it Tokens can be scoped to express least required access Tokens can’t be replayed against other systems Tokens are made to be easy to throw away Unlike user’s credentials or certificates

24 RHEx and NIST Levels of Assurance (LoA)
Defined in National Institute of Standards & Technology (NIST) Special Publication LoA 1 – pseudonymity Same person over course of transaction Typical internet use case OpenID Connect with dynamic registration LoA 2 – identity proofing Claims verified by a trusted source OpenID Connect with whitelisted identity providers All tokens signed by public key or shared secret LoA 3 – multifactor remote protection Recommended that client signs requests OpenID Connect with signed Request Objects Tokens signed and encrypted with public key

25 RHEx and LoA Inheritance from the IdP
Identity assurance starts at the IdP Clients request a certain LoA from the IdP LoA of transaction expressed inside of ID Token issued by IdP Enforce identity proofing by contract or regulation IdPs control who has accounts at the IdP Enforce account proofing at login Integrate with existing local website login systems Can use passwords, certificates, hard tokens, single-sign-on Authentication requirements limited to IdP Note: Trust model can map to DIRECT’s Provider Network

26 RHEx Security Summary RHEx is secure RHEx security is interoperable
Uses same trusted tools used by high volume, secure systems to move money and exchange other sensitive information Secure Transport: all transactions over Transport Layer Security protected HTTP Exchanged tokens verified by trusted 3rd party RHEx security is interoperable Integrates with JSON, XML, HTML, Bluebutton, etc. Supports NIST Level of Assurance up to 3 (IdP dependent) Harmonizes with existing NwHIN standards RHEx security is scalable Documents contain separable links to information – each uniquely securable Allows security and privacy to be applied atomically

27 Questions & Follow-up Questions?
For more information: Discussion on the Google Groups forums (https://groups.google.com/forum/?fromgroups#!forum/restfulhealthexchange)

28 Backups

29 OpenID Connect Family Tree
OAuth 1.0/a XRDS OpenID 2.0 Hybrid WS* ID-WSF WRAP XRD AB AX PAPE SAML OAuth 2 Facebook Connect SWD JWT/JOSE OpenID Connect

30 Security Terminology Identity Provider (IdP) User Information Claim
Service that can assert the identity of a logged in user to a remote system User Information Set of attributes about a user in a system Claim Verifiable attribute about a component in the system In our case, claims on users Token Disposable credential representing a subset of access and capabilities of an entity in the system

31 Basic OpenID Connect Flow (in RHEx Approach)
RHEx site decides and configures which Identity Providers (IdPs) it wants to trust User shows up at remote RHEx site, asks to log in using OpenID Connect at their Identity Provider (IdP) User is redirected to their IdP User logs in to their IdP (using local password, certificate, single-sign-on, etc) User is issued a one-time-use code and redirect back to the RHEx site with that code RHEx picks up that code and sends it to the IdP to get two tokens ID Token contains claims about current session Access Token can be used to get further information about the user, such as profile information

32 OpenID Connect Authentication
User User would like to interact with a RHEx compliant system User shows up at remote RHEx site, asks to log in using OpenID Connect at their Identity Provider (IdP) User has registered with a recognized IdP A site employing RHEx decides and configures which Identity Providers (IdPs) it wants to trust IdP RHEx Site

33 OpenID Connect Authentication
User User is redirected to their IdP User logs in to their IdP (using local password, certificate, single-sign-on, etc) ? IdP RHEx Site

34 OpenID Connect Authentication
User User is issued a one-time-use code and redirect back to the RHEx site with that code + IdP RHEx Site

35 OpenID Connect Authentication
User ID Token contains claims about current session RHEx picks up that code and sends it to the IdP to get two tokens Access Token can be used to get further information about the user, such as profile information + IdP = RHEx Site Now we can use the API as long as that token stays valid.

36 = CheckID User IdP RHEx Site
We can send the ID Token to the CheckID Endpoint to have the server validate it for us, so we don’t have to do client-side crypto. User = IdP RHEx Site

37 = User Info User IdP RHEx Site
We can send the Access Token over to the User Info endpoint to fetch claims about a user, and pointers to remote claims about that user. User = IdP RHEx Site


Download ppt "wiki.siframework.org/RHEx"

Similar presentations


Ads by Google