1 / 10

OAuth Profile

OAuth Profile. Brief Profile Proposal for 2013/14 presented to the IT Infrastructure Planning Committee R Horn (Agfa Healthcare). Problem to be solved.

jeremymorales
Download Presentation

OAuth Profile

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. OAuth Profile Brief Profile Proposal for 2013/14 presented to the IT Infrastructure Planning Committee R Horn (Agfa Healthcare)

  2. Problem to be solved • The mHealth profile does not specify any security profile options. This allows it to cover a very wide variety of use cases, but means that each installation and deployment must resolve the security and privacy controls in a local site specific manner. • OAuth is a widely used authentication and authorization system for consumer and commercial users. • The mHealth profile should have an authorization option. Current market factors make the OAuth framework a leading candidate to profile, with options selected to be appropriate for the mHealth use. • The initial effort will examine other RESTful authorization alternatives, although none appear to have the level of acceptance of OAuth. • This will be an independent profile, with an option defining grouping with MHD. Like the XUA profile, this profile can be grouped with any HTTP-based profile when authorization services are needed.

  3. External Requirements • Continua Requirements • We have consumer devices (e.g. tablet, smart phone …) running personal health applications with corresponding requirements. • Focus on on-the-wire protocols and compliance. • We need an easy/interoperable method for obtaining authorization tokens.  • Leverage RESTful approach for sending measurement observations across the WAN IF. • Leverage RESTful approach for retrieving measurement observation across the WAN-IF. • (non-technical – but equally important) Choice of protocols and technologies that motivate 3rd party independent software vendors (e.g. Apple App Store, Google Play) • Enterprise Healthcare Requirements • Hospitals need to provide authorization services for RESTful access from • Hospital controlled medical devices • BYOD devices • Other enterprise devices

  4. External Requirements • Government agencies • ONC and others are prototyping RESTful authorization services. In the case of ONC, the OAuth 2.0 framework is being prototyped. • Commercial Providers • Various commercial providers have emerged and are requiring that authorization services not be tied to the healthcare provider. The preference is making authorization service selection a patient/user selection.

  5. Assumptions • Assumptions • Authorization services will not be centralized, national, or unified. • Authorization services will be not be healthcare provider selected. • A patient will have their preferred authorization server, • A healthcare provider will have to be able to support multiple authorization servers, and these servers will not be under the control of the healthcare provider. • The selection of authorization services will be a matter for negotiation among patient, authorization services, and healthcare providers. • Healthcare services will need to adapt commonly used authorization services • RESTful services will require authorization • Other options may evolve. (This is why this should be an option rather than part of the base profile.)

  6. Available Frameworks • OAuth 2.0 is the dominant available framework • OAuth 1.x has been successfully deployed for commercial uses with web browsers. • OAuth 2.0 is a subsequent authorization framework that is designed to be profiled for specific uses, and to fix problems found with OAuth 1.x • Other alternatives (these have not received much support outside of the enterprise environment) • Kerberos tokens • LDAP authentication • HTTP password • HTTP SAML • Various proprietary systems

  7. Use Case (OAuth example) Use Case 1 OAuth Auth Request Client Authorization Server Unspecified other traffic OAuth Auth Response OAuth Service Ticket In HTTP headers Use case 2 Service Provider OAuth specifically avoids specifying other traffic and coordination traffic so that different authorization methods can be employed. For example, some authorization servers use tokens and others use password traffic as part of the request process

  8. Proposed Standards & Systems • The proposal is to • Evaluate the alternatives, and profile an authorization method. • Assuming OAuth V.20 from the IETF. • The OAuth framework expects to be profiled with specific information to meet use case specific needs. As a framework, it does not specify all of the requirements for implementation and deployment. • Benefit: The IHE profile can consolidate healthcare specific input to the IETF and OAuth implementers in a manner that they expect to be used.

  9. Profile Structure • This profile will be an authorization profile analgous the the XUA profile. • It will be groupable with any RESTful service profile. • An MHD option will be written to show how implementations can specify and document their grouping behavior.

  10. Discussion • What level of effort do you foresee in developing this profile? • Moderate work effort. • Is there someone who is willing to act as profile editor? • Rob Horn (Agfa), with Brad Generaux (Agfa)

More Related