Stream: smart
Topic: Smart Backend Auth Model
Nichol Hill (May 06 2019 at 22:27):
Hi All,
I was hoping you could provide some input to a question we currently have regarding 2B Authentication and Authorization for access to a set of FHIR API’s
We currently have a design that calls for multiple external organisations to both authenticate themselves and be authenticated at an organisation level authorization, however when each organisation accesses or supplies information via the API’s they need to provide the identity of the individual this is on behalf of (note the identity of the individual is not part of the authentication or authorization flow, it is used as part of an audit log)
We would like to use the smart framework, however, have found two approaches to this being:
a) The approach described at: https://github.com/smart-on-fhir/fhir-bulk-data-docs/blob/master/authorization.md
This approach would likely be simpler for system implementers as they would have a single token for all transactions however may provide some scalability limitations.
b) The approach described at https://github.com/smart-on-fhir/smart-on-fhir.github.io/wiki/cross-organizational-auth
This seems to provide a tighter level of identity control by tying a token to org+provider+patient however may prove a more complex to implement owing to the multiple token management and deprecation involved.
Does anybody have any suggestions on approaches to this? @Grahame Grieve @Josh Mandel @Reuben Daniels @Shovan Roy @Brett Esler @Brian Postlethwaite
As an aside we will not be requiring clients to obtain a client-to-client digital certificate as we will be leverage the exiting PKI infrastructure for health care authentication in place in Australia.
Thanks,
Nichol
Josh Mandel (May 06 2019 at 22:34):
First, context: The first guide that you mentioned has received substantially more attention and review -- It is in the process of being balloted through HL7. The second guide is a draft treated a few years ago that has not received significant attention or review.
Josh Mandel (May 06 2019 at 22:35):
If all you really need is to pass along some information for audit logging, have you worked out requirements like non-repudiation on these?
Josh Mandel (May 06 2019 at 22:36):
(also the language about digital certificates is an error in the specification that will be corrected during this ballot round; The only requirement is that the client registers a public key with the server, which then got to associated with its client ID in that server.)
Nichol Hill (May 07 2019 at 01:59):
Thanks @Josh Mandel ,
Given this information it looks like the most appropriate option would be the fist. In any case we are doing a POC first and can adjust from learnings as required.
There may be some requirment for authorization to be applied based on the details of the individual suppied however authentication would still only be at the orginisational level. Our approach would bb to use the first approach to deliver the org level authentication and authorization then implement individual authentication( token validation) and authorization (check the permissions of the user in context) in the API layer - does this seem resoanable to you?
Josh Mandel (May 07 2019 at 02:22):
If I'm following, then I think so -- but I'm not totally sure what you mean abut these two levels ("first approach" and "then individual authentication".
Nichol Hill (May 07 2019 at 03:58):
Ok, thanks @Josh Mandel ,
Basically the token would be generated for an orginisation and at the time of token generation we would validate the orginisations identity and authenticate then as a valid client to our systems. We would also ensure they are authorised for the scope they ask for and then issue a token. - this would be using the approach described at https://github.com/smart-on-fhir/fhir-bulk-data-docs/blob/master/authorization.md
On a FHIR put, post or get they would include details of the individual that the request is on behalf of. we will not authenticate this individual but trus the authenticated org to correctly identify them. we will in the api layer validate that the individual has approprite authority for the exchange.
Nick Hatt (May 07 2019 at 14:04):
@Nichol Hill the access token can be whatever you want - including a JWT. If you have a centralized service that handles authorization, you can include details of the individual on a JWT, sign it, and have all the decentralized nodes trust a public key from the AuthZ service.
Shovan Roy (Feb 02 2020 at 00:22):
including @Isaac Vetter in this discussion.
Last updated: Apr 12 2022 at 19:14 UTC
