[Question] Auth options about fhir-server-samples HOT 9 CLOSED

microsoft commented on August 26, 2024

[Question] Auth options

from fhir-server-samples.

Comments (9)

brochlabs commented on August 26, 2024 1

Azure B2C is designed for this type of workflow, although you would need to create an api to be called in an auth flow that would allow for correlation between the patient I’d and the new ad user Get Outlook for iOS<https://aka.ms/o0ukef>

…

________________________________ From: medlab001 <[email protected]> Sent: Monday, September 28, 2020 5:06:21 AM To: microsoft/fhir-server-samples <[email protected]> Cc: Subscribed <[email protected]> Subject: [microsoft/fhir-server-samples] [Question] Auth options (#95) FHIR server uses Azure AD to authenticate clients, but I'm also interested in creating a patient self-help portal, where they can manage, update and change their medical info. Does this mean I'll have to create new AD account for all of the users? Or must I add another API on top of the FHIR server that proxies/forwards all to it to manage user auth? I was hoping this would help with the creation of a new example, or some help regarding what direction to take to implement patient login functionality? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub<#95>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AIXRQMISX5U2TJNRLQJH4J3SIBNZ3ANCNFSM4R4J2VXQ>.

from fhir-server-samples.

medlab001 commented on August 26, 2024

Ahh, I see, I missed this. Thanks for that!
If I'd rather use my way of authentication/authorization, how do I handle that?

from fhir-server-samples.

brochlabs commented on August 26, 2024

If you can share some details, I can point you in the right direction, but ultimately with any auth mechanism, you’ll need a way to tie an external claim to the patient record. Using oAuth with an external IDP, like gmail/etc still requires that the system accepting the claim match it to a user configured with the system. AzureB2C handles this by automatically creating that user upon enrollment Get Outlook for iOS<https://aka.ms/o0ukef>

…

________________________________ From: medlab001 <[email protected]> Sent: Monday, September 28, 2020 8:44:19 AM To: microsoft/fhir-server-samples <[email protected]> Cc: brochlabs <[email protected]>; Comment <[email protected]> Subject: Re: [microsoft/fhir-server-samples] [Question] Auth options (#95) Ahh, I see, I missed this. Thanks for that! If I'd rather use my way of authentication/authorization, how do I handle that? — You are receiving this because you commented. Reply to this email directly, view it on GitHub<#95 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AIXRQMM7LWNT2WIXAMH3CETSICHLHANCNFSM4R4J2VXQ>.

from fhir-server-samples.

medlab001 commented on August 26, 2024

Details, well I'm still starting out with this, so I'm actually looking for info on how to accomplish this. From your suggestion, I could use B2C for this, and seems to meet all the requirements, such as user types for access control. In case I go ahead with B2C, how do I tie a user's info to the B2C account? I'll need an API b/w B2C and FHIR server, correct? This API will be the one that checks that the user is authorized to view that information.

Also, after creating the B2C tenant, do I need to migrate all my apps that use it to that directory?

I'll clarify a custom solution once I'm up to speed with B2C usage. Thanks for your help!

from fhir-server-samples.

medlab001 commented on August 26, 2024

@brochlabs
I was able to configure Azure B2C, thanks for the info! With that directly connected to FHIR server, I can see all the info.
This page suggests that external auth is required for fine-grained access, such a patient being able to access only their data. My idea was to use Ocelot to inspect the tokens, (and extended permissions stored, say in CosmosDB) and then forward the request to the FHIR server. Have I got this right?

from fhir-server-samples.

brochlabs commented on August 26, 2024

Essentially yes. I would recommend that you CISO sign off on your final authentication and authorization pattern, but yes, the first piece there would be to determine what your system of record is for determining whom has authorization to a patient record. For example, the EMR or the FHIR server should be the most up-to-date system of record for determining a patient or their authorized contact ( oftentimes you have a legal guardian, parent, or someone whom has power of attorney that would be authorized to view the patient record). On initial authentication, you need a mechanism to query not only the authenticating person's EMR ID, but also their related contacts. You could then store those tokens in Redis Cache so they are available for the session context, etc.

…

On Fri, Oct 9, 2020 at 4:58 AM medlab001 ***@***.***> wrote: @brochlabs <https://github.com/brochlabs> I was able to configure Azure B2C, thanks for the info! With that directly connected to FHIR server, I can see all the info. This page <https://docs.microsoft.com/en-us/azure/healthcare-apis/use-custom-headers> suggests that external auth is required for fine-grained access, such a patient being able to access only their data. My idea was to use Ocelot to inspect the tokens, (and extended permissions stored, say in CosmosDB) and then forward the request to the FHIR server. Have I got this right? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#95 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AIXRQMJ4CEMKYYB3IBRH76TSJ3NCVANCNFSM4R4J2VXQ> .

from fhir-server-samples.

medlab001 commented on August 26, 2024

Yeah this is starting to make sense.
But I ran into an issue. I'm using the Azure API for FHIR, so can't customize the auth pattern there much. For each incoming request, token validation isn't enough. I'll need to check if an physician can view a corresponding patient's data, but there's no such info on the server. If I understood you right, I store this mapping elsewhere, such as a <insert DB + private API, perhaps> and then query it for the given request, and conditionally forward it to FHIR, correct? The trick here, that I must be careful about, is that on new 'relation' (such as a patient being assigned a physician), I must first update my setup, and then update FHIR, so that I'll know what patients to retrieve given a physician. Not sure if I can use Redis here, since it might lose data when there's a crash.

Do let me know if I've got this right.

Thank your very much for your kind help, it's been really invaluable in clarifying how things work, and how I'm supposed to integrate all these.

from fhir-server-samples.

brochlabs commented on August 26, 2024

Correct, determining whom has access to a patient's record requires constraints implemented beyond the FHIR API. The Redis cache was more for retrieving that information and storing it for the context of the session, but you are correct, there needs to be a source system for controlling/requesting/assigning access to a patient record. There is the potential that you could store this information within the FHIR API, using the RelatedPerson endpoint, but I haven't vetted that out yet, and it will be a few days before I can circle back to my API environment. [image: image.png]

…

On Tue, Oct 13, 2020 at 5:26 AM medlab001 ***@***.***> wrote: Yeah this is starting to make sense. But I ran into an issue. I'm using the Azure API for FHIR, so can't customize the auth pattern there much. For each incoming request, token validation isn't enough. I'll need to check if an physician can view a corresponding patient's data, but there's no such info on the server. If I understood you right, I store this mapping elsewhere, such as a <insert DB + private API, perhaps> and then query it for the given request, and conditionally forward it to FHIR, correct? The trick here, that I must be careful about, is that on new 'relation' (such as a patient being assigned a physician), I must first update my setup, and then update FHIR, so that I'll know what patients to retrieve given a physician. Not sure if I can use Redis here, since it might lose data when there's a crash. Do let me know if I've got this right. Thank your very much for your kind help, it's been really invaluable in clarifying how things work, and how I'm supposed to integrate all these. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#95 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AIXRQMIP4XJFB5XVUIOFU4TSKQTLZANCNFSM4R4J2VXQ> .

from fhir-server-samples.

medlab001 commented on August 26, 2024

Thank you for clearing that up!

In B2C, I'm trying to bind the FHIR ID in the user's claims after they register, so that after they login, I can get their FHIR token directly.

I do get the ID in the token "extension_FHIRID": "", after they signin, but I am trying to update it through the graphAPI. The GraphAPI docs only talk about how to create 'open extensions' which are different from extension attributes. I can fetch these through the GraphAPI (_graphService.Users[claimsIdentity].Request().Select($"extension_{b2c-app-id}_{id_name}").GetAsync();), but I can't find any resources on hot to modify them. Could you kindly point me to the right resource?

Thank you for walking me through this, really appreciate your patience, I've made great progress!

from fhir-server-samples.

[Question] Auth options about fhir-server-samples HOT 9 CLOSED

Comments (9)

Related Issues (20)

Recommend Projects

React

Vue.js

Typescript

TensorFlow

Django

Laravel

D3

Recommend Topics

javascript

web

server

Machine learning

Visualization

Game

Recommend Org

Facebook

Microsoft

Google

Alibaba

D3

Tencent