Presentation is loading. Please wait.

Presentation is loading. Please wait.

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.

Similar presentations


Presentation on theme: "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."— Presentation transcript:

1 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 NOTE: This meeting is being recorded and will be posted on the Wiki page after the meeting From S&I Framework to Participants: Hi everyone: remember to keep your phone on mute

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

3 Overview RHEx and the Security Challenge –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 2

4 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) 3 Powering Secure, Web-Based Health Data Exchange wiki.siframework.org/RHEx

5 What Are the Elements of RHEx Security? 4 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 Something you know Something you have Something unique to you

6 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 5

7 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 3 rd 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 6

8 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 7

9 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 whats 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 8

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

11 Traditional EHR Approach in This Model 10 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.

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

13 OpenID Connect Use in the RHEx Model 12 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. Primary Care Specialist

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

15 The RHEx Access Model Start with a simple beginning –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 14

16 RHEx Access Model Simple Beginning Whitelisting individuals –Individual identities tagged as cleared to view a piece of information –OpenID identifiers are like addresses Dont 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 15

17 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 16

18 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 17 { user_id: 12341, name: John Doe, clinicalRole: oncology, oncology: }

19 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 dont 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 18

20 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 19

21 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 todays 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 20

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

23 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 22

24 RHEx Access Model Services Authorization In addition to end user support, RHEx System must allow direct service connections (machine-to-machine) –Cant 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 cant be replayed against other systems –Tokens are made to be easy to throw away Unlike users credentials or certificates 23

25 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 24

26 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 DIRECTs Provider Network 25

27 RHEx Security Summary 26 RHEx 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 3 rd 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

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

29 BACKUPS 28

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

31 Security Terminology Identity Provider (IdP) –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 30

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

33 OpenID Connect Authentication 32 A site employing RHEx 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 RHEx Site IdP User would like to interact with a RHEx compliant system User has registered with a recognized IdP

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

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

36 OpenID Connect Authentication 35 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 Now we can use the API as long as that token stays valid. User RHEx Site IdP

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

38 User Info 37 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 RHEx Site IdP


Download ppt "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."

Similar presentations


Ads by Google