Stream: implementers
Topic: Authorization
Gana Pemmanda (Mar 16 2016 at 19:29):
This is a question about Authorization server. Not sure where to post it, since I couldn't find a stream related to this. Has anyone implemented an authorization server to authorize FHIR resources to specific users/roles/organizations (much like an EHR system)? Would like to get your thoughts on what approach you took - RBAC v/s ACL for each resource v/s Policy (declarative policy using JSON schema) etc.
John Moehrke (Mar 16 2016 at 20:36):
There is discussion of OAuth use in the smart stream. SMART has nailed down a bunch of things so that a realistic environment can be built. There are also other profiles from IHE (IUA) and from an OAuth community (HEART). I have many of these covered on my blog http://healthcaresecprivacy.blogspot.com. and David Hay just blogged on this too http://fhirblog.com/
Gana Pemmanda (Mar 29 2016 at 05:14):
Thanks @John Moehrke for your pointers . I see that SMART does cover part of the Authorization which in most ways is similar to HEART. But the approach seems like the implementation of an authorization server would necessarily be a Acess Control Engine that incorporates security-labels of each resource, Privacy Consent Directive which also allows for User Managed Access. Is that a fairly accurate summary? Has anyone successfully used declarative policy to accomplish this in an authorization server?
Grahame Grieve (Mar 29 2016 at 05:17):
I haven't. SMART assumes that the authorization server and the resource server have carnal knowledge somehow. it doesn't seek to standardize how. Heart/UMA does, but I think that there's a huge amount of learning before we find the sweet spot for the interface between the two.
John Moehrke (Mar 29 2016 at 12:54):
Hi @Gana Pemmanda You are correct. In the same way that SMART is building understanding and maturity around the FHIR Data-Model and Interaction-Model; we also need an effort that builds understanding and maturity around the Security-Model to be applied to FHIR. Similar to how SMART takes a sub-set of the whole of FHIR Data-Model and focuses on it; we need a focus on a sub-set of the whole Security-Model. IN fact this is what SMART has done in that they have focused on the most essential AuthN/AuthZ. What we need is a group that want to take the next step. The next step is not the final step, there are many steps to get to the perfect Security-Model. Is tagging next? Is consent next? Is delegation of authority next? I see activity on defining scopes, a good next step. Many steps to come.
Gana Pemmanda (Mar 29 2016 at 13:20):
Thanks @Grahame Grieve ! I agree about the amount of learning needed :) I just came across of this, and now there is a ton of resources there, particularly Use cases.. For anyone who is in the same boat as me.. http://openid.net/wg/heart/resources/
Particularly this one covers a lot of ground.. http://bit.ly/1USEjjt
Gana Pemmanda (Mar 29 2016 at 13:24):
Hi @John Moehrke. Is there a group focused on Security-Model in FHIR? I would like to join. I am not a security expert, but is that necessary to be part of the group?
John Moehrke (Mar 29 2016 at 13:42):
In HL7, the Security WG (for which I am a co-chair) has a FHIR-Security call tuesday afternoons; and the CBCC WG has a FHIR-Consent call on friday mornings. I welcome implementers, we need your perspective and experience.
John Moehrke (Mar 29 2016 at 13:49):
@Grahame Grieve Yes, one of the current simplifying conditions for SMART is to weld the authorization server and the resource server. This is not unusual for OAuth, but would be only an small step. This is not to say that one must separate them. However there would also be room for a federation of OAuth authorities to be 'in front' of that 'last' authorization server. One clear possibility is to have a federation of OAuth authorities that are just focused on the "OpenID Connect" profile. That is they just do user authentication and authorize the use of that identity. Thus you separate authentication out to these federation of identity providers, from the 'last' authorization server that is making authorization decisions at the resource-by-resource level. Further out (away) is an OAuth authority that 'manages' user assigned authorizations (aka delegation) thus the UMA profile on OAuth.
Josh Mandel (Mar 29 2016 at 14:01):
To be fair, we don't "weld" these services (Authorization server + Resource server) in SMART -- we are just silent about how they are linked. It's very possible to separate them cleanly (and in our reference implementation, we do just that, with a Token introspection API in between).
Josh Mandel (Mar 29 2016 at 14:01):
It's just that this link is orthogonal to the problem we're trying to solve (plugging apps into EHRs and other health IT systems).
Gana Pemmanda (Mar 29 2016 at 14:53):
Thanks @John Moehrke for the info. I will join the security WGs and try to attend those calls as often as I can..
Gana Pemmanda (Mar 29 2016 at 15:26):
Hi @Josh Mandel ! From what I understand, SMART delegates access control to EHRs right? In a scenario where someone comes with a EHR solution in the cloud built using FHIR resources, can SMART be used as an Acess Control Engine (in this case where data from more than one organization / practitioner etc. could reside on the same FHIR resource server) ? Or is this out of scope of SMART's Authorization server?
Josh Mandel (Mar 29 2016 at 15:37):
If you have a system with data, and your system knows which users are allowed to access which resources, then you can use SMART to allow users to delegate those permissions to applications.
Yash Panchal (Oct 22 2021 at 04:30):
Hello Everyone,
I am looking forward to access open EPIC sandbox for exploration using postman client. In order to achieve the same, I have already created account and registered one testing application to get the client ID.
Post registration, I tried to authenticate using client ID but it is not allowing. Can anyone please guide me to access open EPIC sandbox using postman.
Cooper Thompson (Oct 22 2021 at 13:01):
There is a delay between when you create your client ID and when it is available for use in the sandbox. The delay is (at most) 12 hours. If you still have issues, please e-mail open@epic.com and we can help you there.
Last updated: Apr 12 2022 at 19:14 UTC
