Hello, I have a beginner’s question. I know that Gatekeeper is a “sidecar” application (kind of a proxy) that secures applications that don’t have native support for Keycloak (OIDC or SAML). For example, we install our web application at https://my-insecure-application.com and Gatekeeper at http://my-secure-application.com, and we tell users to access http://my-secure-application and Gatekeeper implements OIDC for us. What are my options for stopping users and other parties from accessing https://my-insecure-applicaiton.com directly? I realize this is a beginner’s questions: I’m just trying to understand the options at a high-level.
The way I do it is…
imagine a reverse proxy between “User” and “Gatekeeper”.
You have to configure gatekeeper with a
insecure-application.com can not be publicly exposed.
Gatekeeper is what the name says, sits in front of the protected app.
In my case I have nginx in front that proxies all requests through gatekeeper with a certain conf, which then allows or denies access to the backend “insecure site”.
cors-methods: [GET, POST, PUT, OPTIONS, DELETE]
- uri: /api/v1/*
- uri: /api/v1/*
So in this case I have allowed all GET requests to
/api/v1/* but all other requests to that uri scheme are being checked for validity.
nginx <-> gatekeeper <-> backend
listen is the addr where gatekeeper listens, upstream-rul is the addr of the “insecure” backend.
Like I said before, the backend MUST never be publicly exposed.
Thanks for the detailed reply, dalu!
Is there some simple mechanism for securing the backend internally? I can imagine the reverse proxy sitting at the edge of the network, but inside the “private network”, how do I stop other applications or employees from accessing the insecure application directly? Again, I realize I am a beginner in this: I’m not asking for a complete technical specification, just a high level explanation as to what is possible.
In your backend require the headers set by the gatekeeper.
For instance in one project, when creating, updating or deleting database records, I check if the header
X-Auth-Subject is present and if not, return status 403.
I of course also make sure that a profile associated with this subject exists.
You can also tell the gatekeeper to add headers to the requests that are forwarded to the backend.
and check the presence of those headers in the backend.
You could also not have that backend server mapped in your local dns configuration.
You could configure the backend’s firewall to only allow access from certain IPs.
Many scenarios are possible.
But if you don’t trust your employees… is that a real world scenario or are you making that up?
Because if you’re making it up there’s no use discussing it, since it’s purely fictional. At least for me.
And then why is your backend not on the same host as gatekeeper?
Thanks for your advice, dalu, I will research what you’ve said.
To respond to your question though: Yes, it is a real world scenario. We have many employees, and not all of them should have access. It’s not so much a matter of trust as it is liability and best practice, particularly where personal health data is concerned. (If any one reading this is getting outraged, rest assured I’m not the one in charge of implementing this layer of security; I’m just trying to understand it a bit better.)