Stream: smart
Topic: authorization, tenants, dyanmic registration
Rob Resendez (May 27 2020 at 19:43):
I currently have a different fhir "base url" per tenant. different authorization requirements for patient vs ehr-user seems to make it necessary to have _two_ base urls per tenant. Sure would be fantastic if the spec supported multiple "security metadatas" instead of one (eg: user vs system vs patient) -- for cases like mine where there is just one resource server, but multiple authorization endpoints.
I am also trying to support dynamic registration. I'm having trouble navigating this... it seems that the idea is that the client finds out about the auth server via the metadata / well-known endpoints. How did the client find out about those endpoints??
Curious if others have one client registration that works among its tenants, or are client credentials managed on a per tenant basis?
Michele Mottini (May 27 2020 at 20:21):
You can have multiple tenants (FHIR end points) sharing the same authorization server, but not vice-versa
Michele Mottini (May 27 2020 at 20:22):
How did the client find out about those endpoints??
It is really one end point: the FHIR one - and the client must know it from some internal configuration or setup, there is no discovery mechanism
Jenni Syed (May 27 2020 at 22:42):
In SMART, the FHIR server endpoint is sent to the app (the iss) if it is launched. The app should still whitelist it, but that is the "discovery" today that exists. Standalone apps typically configure this in some way.
Last updated: Apr 12 2022 at 19:14 UTC
