Thursday, September 29, 2011

Securing RESTful services

What is meant by RESTful? Ok, that is an old one; given that there is no such standard as REST. My understanding, RESTful is simply the philosophy of using HTTP built in command set PUT/GET/POST/DELETE (aka Create, Read, Update, Delete – or by others RLUS - Read, Locate, and Update Service). Thus the transport, encoding and command set are fixed. The theory is that you as a programmer then just focus on the special encoding above this command set, for example what is your query parameters and what is the result to look like. Thus freeing you from worrying about transport or command set, and ... security.

As far as securing RESTful services; IHE-ATNA already says how to do that – Mutually Authenticated TLS. I talk at length about this in Securing mHealth - the role of IHE profiles, specifically about the operational reality of using ATNA. IHE ATNA takes care of many risks, and does provide system authentication. Sometimes knowing the requesting system, is enough to know that you can trust that system would only ask for information that it knows the user is authorized to get. Surely using ATNA the service can trust that the client will include the user and purpose in the audit message recorded at the client side, because ATNA requires security audit logging.

What I want to address is deeper than simple HTTPS -- or even full Mutually-Authenticated-TLS. I want to address user and patient based access controls to very sensitive health information. Today RESTful is used mostly to access non-sensitive information. It might be important information, or simply might be maps, earthquakes, weather, etc. Most uses of RESTful are not trying to access as sensitive of information as healthcare information, certainly not information that can have privacy policies (Consents) that rule so finely over the data. Many are asking for RESTful to be used to access fully identified clinical information, and some are even asking that it be used to create or change this clinical information - such as the IHE Profile Proposal for a RESTful interface to XDS. These are the issues that I am trying to figure out how to equally secure RESTful vs SOAP.

In SOAP we have well defined ways to communicate the security context. IHE profiled the use of SAML assertion (XUA): who the user is, what their roles are, what they intend to use the data for, and any authorizations they hold. I cover this in the Bloginar on XUA. With SOAP based web-services this all comes along in the security layer built into SOAP, the WS-Security layer. RESTful doesn't have this layer, or at least not this well defined.

As to providing user identity, there is some hope, but no clear hope. Yes there is a Kerberos for HTTP (documented in EUA). Kerberos has issues when being used beyond a constrained environment, so it is not as suitable for HIE use.

Yes you can use SAML over HTTP. This is not documented in IHE as it is not implemented consistently in toolkits --- but this is used today for browser interactions. For example inside of GE all user authentication uses SAML identities mostly through the SAML "Browser SSO Profile", thus making it easy to work with external parties such as travel reservations. This method doesn't work great for a system-to-system API.  The good news here is that the OASIS committee that handles SAML is working on this very problem now. 

Most RESTful people want to use OpenID now days; which is a good choice for last-mile API; It just doesn't support the necessary user context attributes (role, purpose of use, authentication type) that access to sensitive information really needs. For this the OpenID community adds OAuth, which is fast developing but not mature. OAuth 2.0 looks really good in this camp.

The worst choice for user identity is to use an inline HTML form. This might work for interacting with a human, but as a programming interface it is very hard to work with. This solution locks you into one method of authentication, and one centrally managed user database. Thus proliferating the post-it note problem.


I hope to uncover the 'right' way to specify a RESTful service API for accessing highly sensitive healthcare information. I am not sure I can provide as good a security layer as is provided today with SOAP, but I am hopeful and open to suggestion. IHE will try to figure out all the possibilities, and all the operational environments. Much of the documentation I find is specific to one platform or the other.

I suspect that we will use something like OpenID + OAuth on the RESTful side, use WS-Trust to convert these tokens in the proxy service, so that on the backend we can use SAML to interact with the XDS or XCA backbone. I think this is a reasonable solution. I do expect that a RESTful API will be deployed for a specific use. It might be for the use by a large healthcare organization, or by a PHR vendor, or by a HIE; but the point is that this is an API into XDS/XCA that is hosted for a very specific purpose. Thus the very specirfic purpose can scope the security context well enough to make it easy on the Browser side, while satisfying the needs on the backend.

We could ignore the problem, but then what would "App" developers do? Guess at what they need to have implemented? Even a bad single choice is better than no choice. Even if we tell the App developers to include HTTP Basic Authentication, we will be sure that they can at least do that. Thus only hoping that they have thought beyond the minimal necessary to be compliant with the profile.

Please help. Please provide your choice. Please provide your environmental problem. The more information we have at the start, the better choices can be made.

5 comments:

  1. I tend to advocate for the individual health consumer, e.g., Medicare-eligible people like me and my wife.

    What we would like is a personal health record that can be referenced and updated on-line or off-line, using our PCs and/or smart phone, be kept automatically in synch with the EHRs for all of our health providers, receive and store accumulated data from at-home medical devices, alerts us to health issues based on the care we are or should be getting, serve as a trusted credential for obtaining health care versus filling-out paperwork, contains advanced directives, allows enforceable privacy preferences that are granular on a per-provider and per-person basis, and enables us to view the history of access & updates to our health data across all providers.

    That's a few uses cases for priming the pump.

    ReplyDelete
  2. Glen,

    To the extent IHE would address these use-cases we will include them. But IHE is not an application design group. IHE would focus on the interfaces that the application you describe would use to interface with XDS/XCA.

    ReplyDelete
  3. The uses cases I provided are end-user ones, to be sure. End users do not care about the layers and who does what or not. It's all feature & function. What I described is something that I would be willing to pay a $50 monthly fee per person for, i.e., about the same price as one of those I've-fallen-and-I-can't-get-up gadgets. What we have now are non-interoperable PHRs that are worth only slightly more than what I pay: nothing. I'd like IHE to help remove some of the excuses that are raised when a comprehensive interoperable PHR+EHR regime is described. Then vendors can find a way to get significant monthly fees from me and the rest of the aging Boomers

    ReplyDelete
  4. Glen,

    This is indeed the motivation behind the mHealth proposal that Keith and I are working on. We have heard that the use of SOAP/SAML is a burden. Thus we are trying to offer a lower tech solution with an API of RESTful/OAuth(?).

    Ultimately I really want to see the PHR as an equal-peer on the NwHIN-Exchange. I see no reason why this can't happen. Often times 'business' gets in the way: for example healthcare providers not wanting to share, and PHR services wanting to own everything. A compromise by both is needed.

    But, technology should not be a problem. This is our goal, eliminate technology as the problem.

    ReplyDelete
  5. Neither RESTful nor XDS are the goal. The goal is simpler and more effective health information exchange. Every day it becomes clearer and clearer that the registry/repository model is flawed because it deals with patient consent as an afterthought. OAuth approaches health information exchange from the perspective of consent and RESTful scalability and simplicity is just a side bonus. See G+ for a more complete discussion https://plus.google.com/111566682979991899107/posts/bsCGej8vDpP

    ReplyDelete