Stream: implementers
Topic: HAPI server - Capability Statement and security service
Peter Bernhardt (Jul 07 2020 at 15:37):
I'm implementing a server using the HAPI FHIR server. One of the neat features of this server is that it automatically generates a Capability Statement based on your particular implementation.
I also need to provide the OAuth endpoints in the Rest -> Security -> Service sections of this resource, but I'm not sure how to include this in the auto-generated CS resource. Is there a way to amend the auto-generated resource to do this?
Lloyd McKenzie (Jul 07 2020 at 16:00):
You might ask on #hapi
Peter Bernhardt (Jul 07 2020 at 16:27):
Lloyd McKenzie said:
You might ask on #hapi
Thanks. Subscribed and reposted.
PKumar (Jul 22 2020 at 08:28):
Good Morning/Good Evening.
I am looking to understand about the implementation of capability statement. I went through the HL7 FHIR documentation but in business use case stand point...when should we use capability statement? and does this solve the problem to restricting the users access to specific resource...
Trying to understand the workflow here....lets say client wants to access patient resource. Does this user/client request hits the capability statement resource data to validate the level of permissions defined for this user/client and then proceed with allowing access to the actual resource (lets say patient resource)?
Looking forward to hearing from you. Thanks in Advance.
Lloyd McKenzie (Jul 22 2020 at 14:28):
CapabilityStatement doesn't constrain users. CapabilityStatement declares what a server is capable of doing. It's possible for a server to expose distinct CapabilityStatements to each user based on their permissions. So if you hit a server without authenticating, you would see what the server can do "in general". If you hit it after authenticating as a user, the server would expose a CapabilityStatement constrained to the operations you're actually allowed to invoke.
PKumar (Jul 23 2020 at 13:24):
@Lloyd McKenzie ,I understand it now, Thank You!
Is it mandatory to implement capability statements when I create FHIR server? or it is a best practice to create and expose to the potential/existing clients to ensure they are aware of what actions they can perform?
Robert Scanlon (Jul 23 2020 at 13:31):
Exposing the CapabilityStatement through the capabilities interaction ([base url]/metadata) is required for RESTful FHIR servers. See https://www.hl7.org/fhir/capabilitystatement.html#notes
PKumar (Jul 23 2020 at 15:08):
Thats interesting to know. So, it falls under best practice of implementation then. Thanks @Robert Scanlon
Robert Scanlon (Jul 23 2020 at 15:11):
I believe is stronger than best practice, and is a mandatory requirement for RESTful servers. "RESTful servers are required to provide this resource on demand. Servers SHALL specify what resource types and operations are supported, and SHOULD also specify profiles for each resource type."
PKumar (Jul 23 2020 at 15:19):
Ok, now I got more clarity to it. @Robert Scanlon What other resources fall under this bucket of mandatory requirements?
Lloyd McKenzie (Jul 23 2020 at 15:33):
For a FHIR server, the only mandatory thing is CapabilityStatement at the metadata endpoint. You are a fully conformant FHIR system if you expose metadata and you have a CapabilityStatement that declares that you support no RESTful resources, no messages and no documents. (You're not a useful system, but you're FHIR-conformant :>) Beyond meta, the only requirement is that you do whatever your CapabilityStatement says that you do.
PKumar (Jul 23 2020 at 16:53):
Great!! Thanks for the details @Lloyd McKenzie
Douglas DeShazo (Sep 15 2020 at 14:26):
Has there been any concern expressed about the amount of times an application or client may access the metadata endpoint as it is unsecured? On Demand, as the spec says, means to me it is available at all times regardless of timing, number of accesses, etc.
Lloyd McKenzie (Sep 15 2020 at 14:43):
Why do you presume that it's unsecured? I don't think there's any language that would prevent a system from appropriately responding to DoS attacks or something similar.
Douglas DeShazo (Sep 15 2020 at 16:48):
I was referring to the language in the spec that says 'should' return a CapabilityStatement before authorization/authentication.
Lloyd McKenzie (Sep 15 2020 at 16:51):
Right, but that doesn't mean you can't put in place denial of service protections
Douglas DeShazo (Sep 15 2020 at 17:33):
thanks @Lloyd McKenzie for some reason there was an expectation coming out of Connecathon on my side that authorization/authentication was required and I wanted to double check.
Douglas DeShazo (Sep 15 2020 at 17:34):
or rather that the metadata endpoint was to always remain open/unsecured.
Lloyd McKenzie (Sep 15 2020 at 17:56):
One common behavior is that if someone hits the endpoint without authentication, it provides basic capability information (including how to authenticate) and if you hit it with authentication, it tells you what you're allowed to do with your current authorization.
Last updated: Apr 12 2022 at 19:14 UTC
