Stream: implementers
Topic: Reference Server Security Question
Grahame Grieve (Jul 28 2017 at 10:01):
I have a security question which only makes sense in the context of the reference server. Repeat: I'm not asking about how security works or should work in a real system.
Grahame Grieve (Jul 28 2017 at 10:03):
as a background to my question, my server can now pick up on SSL certificates and JWT bearer tokens to identify the client software and user making a request. And potentially, the server could respond differently depending on whether certificates or JWTs are provided in the request. Of course, I can simply deny access, but for testing purposes I would like to respond differently - and I have real contexts in which users would like to demonstrate how this makes a difference on the API
Grahame Grieve (Jul 28 2017 at 10:04):
so I could say, for instance, that if some resources are marked accordingly, they are only visible to users who have authenticated, where as others are not.
Grahame Grieve (Jul 28 2017 at 10:04):
say, using some kind of tag, or security label
Grahame Grieve (Jul 28 2017 at 10:06):
I'm thinking about this now - anyone have suggestions about how to do this? however it's done, clients need to have access to manage it
John Moehrke (Jul 28 2017 at 12:10):
So the difference between identity as asserted by a certificate authenticated through client-side TLS certificate; is just an identity. Much like various identities asserted by a security token issued by an OAuth authority. With further variability given a set of OAuth authorities, or certificate authorities (Not all authorities need be treated the same). Also various types of roles/purposeOfUse/settings that would be attributes within security tokens and certificates..... These are clear these are all equally possible vectors, right? That is to say a certificate token, vs OAuth token, vs SAML token, vs Kerberos token, vs XYZ token; all have internal attributes about the identity, context, and all are asserted to by an authority which has some level of trust, authority, context.....
John Moehrke (Jul 28 2017 at 12:13):
FHIR Resources have security tags, to differentiate through various data vectors the kind of rules that would be applicable. The FHIR Resource types would also be a vector through rules space. As well as relationships to focused Resources like Provider (authorship, workflow), and Patient (subject). ... Thus Data Vectors
John Moehrke (Jul 28 2017 at 12:13):
Lastly Patient consent provides vectors that express the patients rules.
John Moehrke (Jul 28 2017 at 12:13):
I expect all this is understood by YOU... I am just putting it there so that it is agreed basics.
John Moehrke (Jul 28 2017 at 12:16):
Is your question a question specific to FHIR? Or best-practice in 'Reference Implementation' of access control?
Grahame Grieve (Jul 28 2017 at 12:20):
specific to my server - within that set of possibilities, what's a simple policy I could enforce in the decision engine, such that it allows clients to demonstrate usefully and consistently the effect of different levels of authentication to the server
Grahame Grieve (Jul 28 2017 at 12:20):
my server is... unusual... in that it's sole purpose in life is to serve the FHIR community
John Moehrke (Jul 28 2017 at 12:40):
So, how about enabling READ only for the Resources that make up a Provider Directory; when client authenticated via certificate. That is this level of authentication doesn't get any Patient data, but does get useful data. (Actually this is a useful policy for anonymous)
Grahame Grieve (Jul 28 2017 at 12:43):
so a simple policy that if you don't authenticate at all, you don't get any resources in the patient compartment
John Moehrke (Jul 28 2017 at 12:43):
yes, but that would be anonymous... not what you asked for
John Moehrke (Jul 28 2017 at 12:44):
Or, given that mutual-auth-TLS would be most common in organization-to-organization; access to the Financial Management resources is only allowed through this ... an OAuth token not allowed access to FM resources.
Grahame Grieve (Jul 28 2017 at 12:45):
actually it could be:
- no authentication = nothing
- client authentication with user authentication - everything not in a patient compartmnet
John Moehrke (Jul 28 2017 at 12:46):
Or, (privacy advocate hat off) cert gives FULL access regardless of consent status; oauth access must follow consent enforcement.
John Moehrke (Jul 28 2017 at 12:47):
what is "client authentication with user authentication"? I was expecting certificates to be system (organization) identity claims authenticated using TLS... so would not be 'user'
Grahame Grieve (Jul 28 2017 at 12:50):
SSL certs, yes, that's exactly right. but a client may choose to provide a user assertion as an openID Connect JWT in the HTTP authorization header, which my server will take not of
Grahame Grieve (Jul 28 2017 at 12:50):
and also, I have an openID Connect JWT from the OAuth process
Grahame Grieve (Jul 28 2017 at 12:51):
so in either case, I have an authenticated user, as well as authenticated server software
John Moehrke (Jul 28 2017 at 12:55):
okay, yes... both levels are possible, they are independent but clearly related. So the most trustworthy would be when systems authenticate mutually at TLS level, and also a OpenID Connect JWT at the user level... --
John Moehrke (Jul 28 2017 at 12:57):
Another policy space that is related is where the access policy is dependent on the transport security. Such that for any given user, they might get different access depending on the transport between them and the data. Common example is when Dr Bob is in the hospital, he has highest access; but when Dr Bob is out on the golf course, using his own cellular phone (not corporate black phone) he gets lesser access. This lesser access is usally just readonly vs full read/write access... but might also be access to the most sensitive data is blocked when the pathway is not trustable enough to carry the most sensitive data.
Grahame Grieve (Jul 28 2017 at 12:58):
well, my simple equivalent of that is that if non-SSL interface is running, user can't authenticate at all
Grahame Grieve (Jul 28 2017 at 12:58):
at least, not on the non-SSL interface
John Moehrke (Jul 28 2017 at 13:00):
Yup, that is a good one... not good to trust a user token sent over non secure channel (past lesson learned: firesheep, not having anything to do with FHIR)
Jim Kreth (Jul 28 2017 at 19:04):
Grahame, my team is in a similar position in that we are implementing our FHIR services for internal use by other solution development teams in the company. We are securing access to each FHIR service endpoints with an API Manager that can load balance across many VM's. Access requires a bearer token issued by the API mgr's storefront. We have it set so anyone can request access to our sandbox environment, but access to production services requires an approval / certification process (simple if you only need GET / SEARCH access, more in depth for POST/PUT/DELETE). These access tokens are issued to "trusted" systems/applications. End-user identity is required for most access and will be passed along as JWT and captured in all audits logs. We leave user authentication/authorization (and creation of the JWT token) up the trusted client system. We are toying with idea of a XAMCL server to enable a centralized authorization point, but that'd be a big hurdle for us. BTW, all traffic between servers is https and gated through internal firewalls. FYI, we are using WSO2's APIMgr.
Last updated: Apr 12 2022 at 19:14 UTC
