How to stop users from directly accessing the web application behind Gatekeeper

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.

gatekeeper

The way I do it is…
imagine a reverse proxy between “User” and “Gatekeeper”.
You have to configure gatekeeper with a upstream-url.
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”.

discovery-url: https://connect.domain.tld/auth/realms/somerealm.tld
client-id: web-client-pkce
listen: unix:///tmp/somerealm.tld-proxy.sock
enable-refresh-tokens: true
encryption-key: 3ptog8xsa9eKyafXJWIUBZpQfPFXSO1G
upstream-url: unix:///tmp/somerealm.tld.sock
secure-cookie: false
no-redirects: true
verbose: true
cors-origins: ['*']
cors-methods: [GET, POST, PUT, OPTIONS, DELETE]
cors-headers: ['*']
resources:
- uri: /api/v1/*
  methods:
  - GET
  - HEAD
  - OPTIONS
  white-listed: true
- uri: /api/v1/*
  methods:
  - DELETE
  - PATCH
  - POST
  - PUT
  - TRACE

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

Note listen and upstream-url.

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.

1 Like

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.

gatekeeper2

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.
https://www.keycloak.org/docs/latest/securing_apps/#custom-headers
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?

1 Like

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.)