Wednesday, November 30, 2016

Is IUA (OAuth) useful in Service-to-Service http REST (#FHIR)?

My last article was regarding if XUA (SAML) was useful in a Service-to-Service SOAP exchange. The same question came to me regarding FHIR and http REST. It was not as well described, as it was in a phone call. But essentially the situation is very similar. There are two trading partners that have an agreement (Trust Framework) that one will be asking questions using FHIR http REST interfaces of the other party.

Using Mutual-Authenticated TLS

The initial solution they were thinking of was to simply use Mutually-Authenticated TLS in place of the normal (Server Authenticated) https.

This is easy to specify, and is consistent with IHE-ATNA.

This solves authentication of the server to the client, and authentication of the client to the server.

This solves the encryption and data integrity (authenticity) problem.

Thus keeping EVERYONE else on the internet out of the conversation.

The negative of this is that one must manage Certificates. One issued to the Client, One issued to the Server. The more clients and servers you have, the harder the management of these Certificates become. As this number approaches a large number (greater than 2 by some peoples math, greater than 20 by others) it becomes more manageable to involve a Certificate Authority. You can use a Certificate Authority from the start, but it is not that critical. Some Operational-Security-Geeks will demand it, but often they are misguided..

So at this point we have a simple solution, that addresses the issues.  It looks very good on paper.

Problem with Client authenticated TLS

There is however an practical problem that might cause you pain. It caused me pain as soon as the project I was on tried to implement this at scale. At scale, one tends to use hardware assistance with the TLS protocol. There are many solutions, in my example it was F5 based load balancing hardware based TLS support. These fantastic device make TLS --- FAST --- But their default configuration doesn't include Mutual-Authenticated TLS. They have Mutual-Authenticated TLS, it can be configured.

The next problem is that the TLS acceleration box strips off TLS; meaning that my web-server gets no indication of the identity of the client. If the situation is that I don't have different Access Control rules, this might not be a big problem. However I don't have a way to record in the Audit Log who the client is. If the client is exactly ONE system, then I can guess that it is that system.

The good news is that the TLS acceleration box can likely be configured to pass along that client identity from that TLS client authentication. In my case, there was a chapter in the F5 documentation that told me how to write the script to be inserted in the F5 so that it would extract the Client Identity, and stuff it into a http header of my choosing. Thus my web server could look at that header for the identity of the client. Of course I had to make sure that the header NEVER came from the external world, or it wouldn't be an indication of a authenticated client.  This is a kludge, but a defendable one.

Using OAuth is better?

So, using OAuth for client authentication, while just using normal https (server only authenticated TLS) is far easier to configure on the server. In fact it is supported by the default cloud stacks.

The advantage of this is that the OAuth token gets forwarded directly to your web stack, where it can be used for Access Control and Audit Logging.  It can be verified, based on OAuth protocol (and all the security considerations left open by OAuth). Really nice for both service orchestration and 'scale' is that it can be further forwarded to sub-services which can validate it, use it for access control, and audit logging.  This is really important feature if you have a nice modular service oriented architecture.

The drawback of OAuth is that you must include an OAuth authority in the real-time conversation. Where as with Mutual-Authenticate-TLS, the certificate is issued once and good for a couple of years; the OAuth token is often only good for 24 hours, or 8 hours, or less. You could issue 2 year OAuth tokens, but that is unusual.

I need to note that in order to use OAuth you do need to deal with registering the client 'application'; which is often done via a static secret (password like), or via a certificate... Everything ultimately does come down to a secret or certificate. I would recommend certificate, but realize that is not the common solution. Most implement only secret key.

Both is better?

Not really. The only benefit you get by using both Mutually-Authenticate-TLS and OAuth is that the hardware accelerated TLS box (F5) can reject bad clients with less overhead on your web-stack. This is a benefit, but you need to weigh this against the cost of certificate issuing and management.

It is however better in that it has the fewest hacks to get it to work fully.

Conclusion

As easy as http REST is, aka FHIR, it is very hard to get security right. Sorry, but the vast majority of http REST is either completely non-secured content, simple security. Such as Wiki, Blog, or Social networks. None of them are dealing with sensitive content that is multi-level sensitive. It is this that makes healthcare data so hard to secure and respect Privacy.



Friday, November 25, 2016

Is XUA useful in service-to-service?

I got an email question asking if the use of XUA is proper for situations of service-to-service communication.
I am not sure how far XUA really got in the IHE world, but we have an HIE in XYZ [sic] that seems to want to implement it on every IHE transaction, even those without a document consumer. Our role with them is strictly at a system level as a document provider and of course we are using Mutual Authentication
Reading the XUA spec it seems that IHE was gunning for consent authorization of a document consumer and those transactions, though it never actually came out and said "just" those transactions. SO my questions.
Does the IHE have a stance on this ? Are all transactions(XDS and PIX PDQ) to use SAML ? Or is the spirit of the law about consent and document consumption calls ?
How much is XUA used... very hard to know. But the concept of XUA is simply that a requesting party identify the requesting agent using SAML. Where that agent is usually a human in an interactive workflow. If we recognize that XUA is simply the use of SAML, no any specific subset, then I would say it is very universally used. In many cases, the server is ignoring it completely, in a few more it is doing nothing but recording in an audit log, but in a few it is being used in an Access Control decision. All of these are the vision of XUA.

XUA is also not tied to XDS, it is tied to SOAP transactions. These are mostly found in the XDS family (XCA, XDR, XDS), but also exist in some patient lookup transactions like (XCPD, PIXv3, and PDQv3). However there is no clear binding between SAML and HL7 v2 transactions like (PIX, and PDQ). It is not clear how one would identify the user in cases of HL7 v2. Note that you could identify a user in PDQm, and PIXm using IUA; but that is a different blog - Internet User Authorization: why and where.


XUA does include a number of optional attributes; specifically use-cases that when needed shall be satisfied a specified way; but the use-cases are not mandatory. There are indeed a few consent focused use-cases in this optional space. If the client needs to inform the server of a specific consent that authorizes access, THEN it is communicated thus. Other more commonly used use-cases are those around the name of the user, and the purpose of use for the request.

XUA is independent of consent, although many times consent is specific down to the user.

XUA is most often useful when the requesting party is a human, but that is not the only useful scenario.

However it is not unusual to use XUA to identify the service that is making a request, even if it is redundant to the TLS 'client' certificate. The SAML assertion is more expressive, and including it allows for future expansion to utilizing this more expressive capability.

On a practical perspective, it is common for TLS to be terminated at the very edge of a cloud infrastructure. It certainly authenticated the calling system. But being terminated in a TLS specific piece of equipment, that identity is not available for Access Control checks that will happen later. This kind of a configuration simply can't make access control decisions based on the TLS client identity (Or can't without some hacks in the service stack).

Conclusion

So I think it is reasonable that you are being asked to include a SAML assertion in all requests, even those that are automated and for which the only identity you can claim is the automated service itself. It is this analysis that does need to be done, what triggered the request. That agent that triggered the request is the one that needs to be identified. It is likely today to be a background task, not a human. Background tasks can be identified in SAML just as well as humans can.

Monday, November 21, 2016

Starting to blog again

Sorry to my audience for not getting much from my blog lately. The transition to working life again has been distracting me. I am very sick of forms. I realize that I benefit from the forms being online using browser from the comfort of my home. I can only imagine a few years ago when all of this training and forms would be in-person and on paper.

Some blog topics:

  1. IHE (ITI and possibly others) Plans for next year...
  2. Finish out my Privacy Consent topic with detailed breakdown of the abstract (done) into 
    • IHE-BPPC, 
    • IHE-APPC, 
    • HL7-CDA-Consent, 
    • HL7-FHIR-Consent, 
    • Kantara-Consent-Receipt, and 
    • OAuth and UMA
  3. IHE role in a FHIR world
  4. Adding sensitive data to a Health Information Exchange
  5. Something useful about Blockchain... 
  6. Something assertive about OAuth and FHIR


I often write an article based on some random question I got via email.. so please ask me random questions. You can try to use my blog "Ask Me A Question"

Tuesday, November 1, 2016

Starting my new chapter

I start my new job today. No office to go to, home is my office. I now work for a consulting organization "By Light Professional IT Services, Inc" that has a 4 year contract supporting and enhancing the Health Information Exchange capability of the VA healthcare (VHA) to the rest of healthcare. I am a Standards Architect, doing the same thing I did for GE, standards creation and use. Working for the government I have had a few dozen forms to fill out; get fingerprinted; then hours of training.

I will still be blogging about the standards developments, and implementation guidance on implementing those standards. I likely will be covering Privacy and Security less; heading more into transports and content.