Restricting access to the administration console #12481

pedroigor · 2022-06-13T13:04:10Z

pedroigor
Jun 13, 2022
Collaborator

Keycloak no longer provides capabilities for filtering HTTP requests as per https://www.keycloak.org/docs/16.0/server_admin/#ip-restriction.

The capability was available from the legacy distribution and no longer exists in the official (Quarkus-based) distribution.

The main use cases for this feature are related to:

Users lack control over the proxy configuration so they can't rely on the access control mechanisms provided by the proxy implementation
Users are not exposing the server through a reverse proxy and they need to restrict access to the administration console

Although the use case #2 is a corner case because it does not works well in a HA environment, the use case #1 is something to consider because you might be using a LB from some cloud provider that either does not provide the filtering capabilities or makes the configuration really hard.

The proposal here is to provide a similar capability to the official distribution so that users can:

Enable/Disable HTTP request filtering to the administration console
Configure filtering based on IP Address

Out of scope:

Filter URLs other than the administration console related resources

@thomasdarimont Did some work already in this regard that we can probably use as a baseline

https://github.com/thomasdarimont/keycloak-project-example/blob/main/keycloak/extensionsx/src/main/java/com/github/thomasdarimont/keycloakx/custom/security/AccessFilter.java

Reference:

[keycloak 17.0.1] restrict ip access for keycloak admin console #12394

thomasdarimont · 2022-06-13T20:04:42Z

thomasdarimont
Jun 13, 2022
Collaborator

I played with some syntax variants for configuring an IP based access filter

Variant 0: Just admin-console

admin-console.allow=10.0.0.0/8,172.16.0.1/12

Variant 1: Support for named (admin-console, admin) endpoint settings:

$named-endpoint.access-filter.enabled=true|false # or treat a value for `allow` as implicitly enabled
$named-endpoint.access-filter.allow=CIDR IP Addresses

e.g.:

# Restrict access to admin-console
admin-console.access-filter.enabled=true
admin-console.access-filter.allow=10.0.0.0/8,172.16.0.1/12

Explicit admin endpoint settings:
# Restrict access to admin endpoints
endpoint.admin.access-filter.enabled=true
endpoint.admin.access-filter.allow=10.0.0.0/8,172.16.0.1/12

Variant 2: Support for generic path based settings:

(needs to be http-relative-path aware)

access-filter.allow=$PATH:$IP_Range1|$IP_Range2,...,$PATH:$IP_Range3

e.g:

access-filter.allow=/admin/console:10.0.0.0/8|172.16.0.1/12,/admin:10.0.0.0/8

An implementation for variant 2 can be found here: https://gist.github.com/thomasdarimont/9eae2f8044f8e076eb0c14a3db288b9c
Perhaps the Quarkus folks could provide something along those lines out of the box :)

2 replies

pedroigor Jun 14, 2022
Collaborator Author

One approach I did not consider yet is relying on Quarkus capabilities for protecting endpoints as per https://quarkus.io/guides/security-authorization. It should be possible to wrap those options and provide one specific policy to restrict access based on IP.

farnulfo Jan 3, 2023

Hi, https://quarkus.io/guides/security-authorization don't exist anymore.
Is https://quarkus.io/guides/security-overview-concept the new link ?

boschcrank · 2022-06-16T16:30:12Z

boschcrank
Jun 16, 2022

To add something to the discussion, one of our colleagues asked for this in https://groups.google.com/g/keycloak-dev/c/X5zXIa2hjBQ?pli=1 and Thomas provided him with basically the above SPI based solution. We currently have this IP whitelisting implemented (as extension) and configured for our Keycloak.X instances but it would be definitely better to have this integrated into Keycloak itself. Should we jump in and work on a solution PR?

4 replies

pedroigor Jun 20, 2022
Collaborator Author

Works for me.

I had a quick look at the quarkus-security extension and how we could leverage the security capabilities from Quarkus as per my previous comment. It is definitely possible to do it but I'm afraid that by doing it we are going to create a strong dependency on Quarkus for this capability.

Long-term, a JAX-RS based solution as @thomasdarimont did should be better if the runtime changes again (hope not so soon :)). That said I would highlight the following requirements:

JAX-RS Filter that delegates to a RequestFilterSPI (open to a better name) to actually filter requests
The SPI should be runtime agnostic and if needed rely on standard JAX-RS API
The configuration should be done using the provider configuration
The filter is disabled by default and not installed into the session factory
The filter is only enabled by setting the corresponding options

Wdyt?

boschcrank Sep 7, 2022

I started working on a solution based on @thomasdarimont s work. Still have to figure out how to integrate the request filter from the SPI into the JAX-RS flow.

boschcrank Nov 1, 2022

Problems arise when implementing the requirement "The filter is disabled by default and not installed into the session factory". Since this will be a ContainerRequestFilter, it seems to me that the only way to get the filter into the ContainerRequestFilterRegistry is to add the class in org.keycloak.services.resources.KeycloakApplication, as it is with org.keycloak.services.filters.KeycloakSecurityHeadersFilter. But then this is neither conditional (checking whether the filter is enabled has to be moved to the filter() method then) nor does this allow for arbitrary request filters to be defined.

An alternative way would be to add the request filter in the init() method of it's ProviderFactory programmatically, depending on whether it is enabled or not:
ResteasyProviderFactory.getInstance().getContainerRequestFilterRegistry().registerClass(IpAccessFilter.class);, but this does not work due to the fact that the ResteasyProviderFactory is not the same there as it is when running a request.

boschcrank Jan 17, 2023

Finally managed to create a PR: #16497 (thanks to @ioemat )

yevgeniyo-ps · 2022-09-04T12:17:30Z

yevgeniyo-ps
Sep 4, 2022

I can explain our use case.
We want KC be available from open internet and restrict only admin console.
URL's separation will be useful her:

Main KC endpoint will be resolved to public ingress, LB, WAF etc.
Admin endpoint will be resolved only to internal LB...

This way we wont manage IP's of our admins if they works from home for example

P.S. Our VPN solution dont have public IP for allowing it once...

0 replies

minusdavid · 2022-10-26T23:24:14Z

minusdavid
Oct 26, 2022

I'm curious why the /server_admin/#admin-endpoints-and-admin-console section was dropped from the docs. On one hand, I can see removing it because the Wildfly functionality was no longer available. On the other hand, it sounds like Keycloak no longer recommends that people "Do not expose administrative endpoints externally if external access is not necessary"?

It seems like a good first step would be to bring back that section? In the past, the recommendation was to control access to requests to "/auth/admin", but with Quarkus I think it's requests to just "/admin"? With /admin covering both the admin console and REST API as noted at https://www.keycloak.org/docs-api/19.0.3/rest-api/index.html

2 replies

dasniko Oct 27, 2022

👍 Good catch!
At least the pointer/hint/advise to not expose the /admin path to the internet should be available again, IMHO. For a how the docs may point the user to consult the docs of their used environment infrastructure, like loadbalancers, proxies, etc.
Additionally, a hint to the possibility to configure the admin path with a separate hostname (hostname-admin / hostname-admin-url) would be a helpful enhancement.

minusdavid Oct 27, 2022

I'd be happy to resurrect https://github.com/keycloak/keycloak-documentation/blob/16.0.0/server_admin/topics/threat/admin.adoc in a pull request with the advice to not expose /admin using a reverse proxy or other means.

However, I'm not familiar with the Quarkus distribution, so I'm not sure what to say about configuring the admin path with a separate hostname. Perhaps a follow-up to my PR could be sent with that advice?

Restricting access to the administration console #12481

Uh oh!

pedroigor Jun 13, 2022 Collaborator

Replies: 4 comments · 8 replies

Uh oh!

Uh oh!

thomasdarimont Jun 13, 2022 Collaborator

Uh oh!

pedroigor Jun 14, 2022 Collaborator Author

Uh oh!

Uh oh!

Uh oh!

Uh oh!

pedroigor Jun 20, 2022 Collaborator Author

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

pedroigor
Jun 13, 2022
Collaborator

Replies: 4 comments 8 replies

thomasdarimont
Jun 13, 2022
Collaborator

pedroigor Jun 14, 2022
Collaborator Author

pedroigor Jun 20, 2022
Collaborator Author