-
Notifications
You must be signed in to change notification settings - Fork 157
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow to run the Server without TLS #331
Comments
Chatted with Alexander on Zulip, and this is the elaboration of the discussion/issue. |
prb112
added a commit
that referenced
this issue
Dec 30, 2019
Signed-off-by: Paul Bastide <pbastide@us.ibm.com>
Added fhir-server-webapp/target/fhir-server-notls.war to the build |
Assigned Lee as Reviewer. |
prb112
added a commit
that referenced
this issue
Jan 6, 2020
Signed-off-by: Paul Bastide <pbastide@us.ibm.com>
Team agreed to remove the constraint. |
Constraint is removed. |
prb112
added a commit
that referenced
this issue
Jan 6, 2020
Allow to run the Server without TLS #331
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Is your feature request related to a problem? Please describe.
I our deployment environment, we like to run services without TLS enabled, behind a central TLS terminating load balancer like HAProxy. The reason for this decision is, that we believe that reverse proxies like HAProxy are more secure and reliable in doing horizontal things like TLS termination. Outsourcing TLS to a reverse proxy also makes the service implementing vertical solutions simpler and so easier to maintain and to configure. I also like to refer to The Twelve Factor App here.
Describe the solution you'd like
I like to have a way to configure a binary version of the FHIR server to run without TLS termination enabled.
Describe alternatives you've considered
An alternative is to run TLS behind the central TLS terminating load balancer to connect to the FHIR server. Although that would be possible, managing those certificates would mean a maintenance overhead.
Additional context
I assume an environment of lightweight services which conform to the rules laid out in The Twelve Factor App referenced above. That apps usually bring standalone HTTP endpoints and don't need application servers capable of things like TLS termination. I also assume to have something like Kubernetes as deployment target, were it is even easy to deploy a TLS terminating reverse proxy inside a pod, not exposing any HTTP traffic over the network. So I would be fine if my feature request will be refused, because the intended deployment targets of the FHIR server are different.
The text was updated successfully, but these errors were encountered: