Stream: implementers
Topic: Conveying Source User
Grahame Grieve (Jun 13 2017 at 02:33):
I'm working with an implementer that has a trusted system <--> system FHIR interface, secured by certificates. They need for the client system to inform the server system about the user it is acting on behalf of - without getting that user into the picture (e.g. OAuth). It's for audit purposes.
Grahame Grieve (Jun 13 2017 at 02:34):
I haven't seen any standard pattern for this. Some ideas come to mind:
- an http x- header (seems.... suspicious)
- using the provenance header (seems heavy)
- using an AuditTrail event (really?)
- .. something else?
Christiaan Knaap (Jun 13 2017 at 08:06):
Is this to be expected to work in a standardized way outside of a trusted environment? I would think not really. Thus, I doubt whether we should even try to standardize this. With Vonk we offer extensibility points to handle whatever means you want to use to convey this user and turn it into something you may want to save or log on the other end.
Grahame Grieve (Jun 13 2017 at 10:02):
Agree that we wouldn't standardise this. I'm just asking about best practices so I have a sense of what people are thinking
John Moehrke (Jun 13 2017 at 15:25):
Grahame, given that the real authentication is system to system... anything conveyed in the communication is equally trust-able. This goes for parameters equally to some statement of the user identity... Clearly security would recommend a security token (SAML, OAuth, Kerberos, etc); but reality often dictates that more simple means are sometimes used. My experience has seen a simple username string carried in the http auth header (there is a flavor with just the username), carried s a query parameter, or carried as part of a call-context. Each of them is simply a string, being asserted by the requesting system, where the requesting system is strongly authenticated and authorized with channel encryption/integrity protection (aka Mutual-Authenticated-TLS).
Igor Sirkovich (Jun 13 2017 at 20:00):
In Ontario, we deal with similar trusted system to system interfaces where we convey user information along with under-authority-of and on-behalf-of information in the security tokens (SAML & JWT) .
Grahame Grieve (Jun 13 2017 at 22:01):
k thanks. We'll go JWT
Brian Postlethwaite (Jul 10 2017 at 02:18):
In the header?
Grahame Grieve (Jul 10 2017 at 05:20):
yes
Grahame Grieve (Jul 10 2017 at 05:21):
a JWT (openID connect one) in the header to identify the user, and an SSL cert to identify the system
Brian Postlethwaite (Jul 10 2017 at 05:57):
Cool, thanks
Last updated: Apr 12 2022 at 19:14 UTC