I'm not 100% sure about this. At the same time, I understand the motivation and I agree that it helps to keep this form of access control within the server boundaries rather than forcing people to configure their proxies.

That said, I'm not against it if there is a consensus and demand from the community that it is going to make life easier when deploying and managing Keycloak in production.

W.r.t. to the proposed changes, I think it makes sense to have separate settings for controlling access to both console and API.

I'm also wondering how the admin console feature somewhat here overlaps with the adminUrl in the default hostname provider. It also helps to avoid access to the admin console if you are using a private URL.

Perhaps a more generic solution would be to have a JAX-RS filter that intercepts requests and checks whether an endpoint is enabled or not. It should help to avoid boilerplate code we have here as well as serve as a central point for managing access to whatever API we expose. Endpoints could be annotated with EnvironmentDependentProviderFactory (perhaps rename it to something more generic).

In Dist.X, we are currently managing features like:

./kc.sh --features-admin_api=disabled --features-admin_console=disabled

However, for this one, I think it would make more sense to provide specific configuration options like:

./kc.sh --no-admin-console
./kc.sh --no-admin-api

Not necessarily related to this problem, but perhaps we should also have a features command too? Similar to what we are discussing about providers?

./kc.sh features [--name] [enabled|disabled|list]

I'm not 100% sure about this. At the same time, I understand the motivation and I agree that it helps to keep this form of access control within the server boundaries rather than forcing people to configure their proxies.

That said, I'm not against it if there is a consensus and demand from the community that it is going to make life easier when deploying and managing Keycloak in production.

W.r.t. to the proposed changes, I think it makes sense to have separate settings for controlling access to both console and API.

I'm also wondering how the admin console feature somewhat here overlaps with the adminUrl in the default hostname provider. It also helps to avoid access to the admin console if you are using a private URL.

Perhaps a more generic solution would be to have a JAX-RS filter that intercepts requests and checks whether an endpoint is enabled or not. It should help to avoid boilerplate code we have here as well as serve as a central point for managing access to whatever API we expose. Endpoints could be annotated with EnvironmentDependentProviderFactory (perhaps rename it to something more generic).

In Dist.X, we are currently managing features like:

./kc.sh --features-admin_api=disabled --features-admin_console=disabled

However, for this one, I think it would make more sense to provide specific configuration options like:

./kc.sh --no-admin-console
./kc.sh --no-admin-api

Not necessarily related to this problem, but perhaps we should also have a features command too? Similar to what we are discussing about providers?

./kc.sh features [--name] [enabled|disabled|list]

I'm not 100% sure about this. At the same time, I understand the motivation and I agree that it helps to keep this form of access control within the server boundaries rather than forcing people to configure their proxies.

That said, I'm not against it if there is a consensus and demand from the community that it is going to make life easier when deploying and managing Keycloak in production.

W.r.t. to the proposed changes, I think it makes sense to have separate settings for controlling access to both console and API.

I'm also wondering how the admin console feature somewhat here overlaps with the adminUrl in the default hostname provider. It also helps to avoid access to the admin console if you are using a private URL.

Perhaps a more generic solution would be to have a JAX-RS filter that intercepts requests and checks whether an endpoint is enabled or not. It should help to avoid boilerplate code we have here as well as serve as a central point for managing access to whatever API we expose. Endpoints could be annotated with EnvironmentDependentProviderFactory (perhaps rename it to something more generic).

In Dist.X, we are currently managing features like:

./kc.sh --features-admin_api=disabled --features-admin_console=disabled

However, for this one, I think it would make more sense to provide specific configuration options like:

./kc.sh --no-admin-console
./kc.sh --no-admin-api

Not necessarily related to this problem, but perhaps we should also have a features command too? Similar to what we are discussing about providers?

./kc.sh features [--name] [enabled|disabled|list]

Let's think a bit broader about this than just the admin console, as the "--no-admin-console" doesn't make much sense to me. Ideally it would be very easy to disable capabilities you don't need from Keycloak. Don't want LDAP sure, just remove it. Don't want SAML, again sure just remove it. Want to have background service (like cleanup jobs) run in a separate set of nodes that don't handle request, again just do that.

Now if we align features/providers a bit more, and make it easy to define what you want to include in a consistent way, then we have an easy way to do that with Quarkus right, which basically removes features/providers completely from the runtime.

Let's think a bit broader about this than just the admin console, as the "--no-admin-console" doesn't make much sense to me.

It is an attempt to make this setting more explicit when deploying into production rather than having to configure features (more verbose). Similarly to what we are planning for the hostname provider.

Ideally it would be very easy to disable capabilities you don't need from Keycloak. Don't want LDAP sure, just remove it. Don't want SAML, again sure just remove it. Want to have background service (like cleanup jobs) run in a separate set of nodes that don't handle request, again just do that.

Now if we align features/providers a bit more, and make it easy to define what you want to include in a consistent way, then we have an easy way to do that with Quarkus right, which basically removes features/providers completely from the runtime.

Sure, and that is related to the long-term modularization story we have been discussing. For now, we can't do much and my suggestions were based on what we have today. Dist.X can not help much because we have some constraints in our codebase that block us from properly adding/removing features. For instance, if you remove LDAP you also need to remove UIs, mappers, etc, all that spread in different modules.

If we had features (and their providers) self-contained, we could definitely have something in Dist.X. For instance, we would have a very basic distribution with only the core bits. Additional stuff like the LDAP, SAML, etc, would be deployed similarly to what we are doing for custom providers. With the possibility to fetch these extensions from some marketplace, etc. That would be awesome, ideed.

Let's think a bit broader about this than just the admin console, as the "--no-admin-console" doesn't make much sense to me.

It is an attempt to make this setting more explicit when deploying into production rather than having to configure features (more verbose). Similarly to what we are planning for the hostname provider.

Ideally it would be very easy to disable capabilities you don't need from Keycloak. Don't want LDAP sure, just remove it. Don't want SAML, again sure just remove it. Want to have background service (like cleanup jobs) run in a separate set of nodes that don't handle request, again just do that.
Now if we align features/providers a bit more, and make it easy to define what you want to include in a consistent way, then we have an easy way to do that with Quarkus right, which basically removes features/providers completely from the runtime.

Sure, and that is related to the long-term modularization story we have been discussing. For now, we can't do much and my suggestions were based on what we have today. Dist.X can not help much because we have some constraints in our codebase that block us from properly adding/removing features. For instance, if you remove LDAP you also need to remove UIs, mappers, etc, all that spread in different modules.

If we had features (and their providers) self-contained, we could definitely have something in Dist.X. For instance, we would have a very basic distribution with only the core bits. Additional stuff like the LDAP, SAML, etc, would be deployed similarly to what we are doing for custom providers. With the possibility to fetch these extensions from some marketplace, etc. That would be awesome, ideed.

My point there was more in terms on how Keycloak.X should allow users to enable/disable features/providers. We don't want to make that into an "API" that has to change in the future though, and I'm pretty much sure we don't want a "--no-" option ;)

Some random thoughts/ideas (I'm only thinking about how it would be configured from Keycloak.X, not the implementation/improvements there, as for now we can just wire it up to what we currently have):

• Combine features/spis/providers into a single thing that can be enabled/disabled
• Short-hand options to enable/disable a specific capabilities
• Perhaps a "profile.properties" or something that can list what capabilities should be enabled/disabled separately

Let's for arguments sake that we call these capabilities not to conflict with existing things like features/spis/providers. Then we can build some hierarchy of capabilites, so something like:

• admin
• admin/api
• admin/ui
• federation/ldap
• protocol/saml
• db/postgres

Then instead of listing "providers" with kc you'd list capabilities, which could behind the scenes be just a profile feature, a complete spi, or a provider of an spi.

It could also align with setting the default provider, or with the high-level "type" of something we have, so some ideas on how this could look like in Keycloak.X:

kc --db=postgres --admin=disabled --protocol.saml=disabled

Or with a separate profile properties file or whatever:

myprofile

admin.ui=enabled
db=postgres

kc --profile=myprofile

@thomasdarimont sorry for taking you're simple PR and making it into a complex discussion ;)

@stianst I see where you a heading to. As I mentioned before, the example you gave for admin=disabled is somewhat similar to what we support today using --features-admin=disabled.

Let us discuss that in a separate discussion, I'm going to create one.

Let us discuss that in a separate discussion, I'm going to create one.

Thanks

Would be nice to get this in. @thomasdarimont are you still interested in this one?

With regards to how to disable it that should just be done like we're disabling other features (https://www.keycloak.org/server/features#_disabling_features).

For the names of the features "ADMIN_API" is fine as that aligns with ACCOUNT_API, but not sure about ADMIN_CONSOLE, as we have ADMIN2 to enable the new admin console.

Perhaps what we should do is add "ADMIN" feature, that enables/disables the old admin console. This should just be marked as deprecated straight away.

Update so that it doesn't fallback on the old admin console if ADMIN2 is not enabled. Essentially that'd mean to use the old admin console you'd need to run:

bin/kc.sh --features=admin --features-disabled=admin2

Or, if you want to disable the admin console fully you'd just run:

bin/kc.sh --features-disabled=admin2

@stianst I just rebased this branch and applied the suggested changes.

I'm happy with the PR in it's current state. Let's stop nit-picking this one to death ;)

/rerun

@thomasdarimont Looks like there are some related failures. Could you please check them out?

I just rebased this branch on current main, squashed the commits and adapted the failing tests in ProfileTest.

/rerun

@thomasdarimont some tests are failing, which looks like real issues rather than the usual unstable tests. At least one thing I noticed is that adminConsoleEnabled is not added to https://github.com/keycloak/keycloak/blob/main/quarkus/runtime/src/main/java/org/keycloak/quarkus/runtime/services/resources/QuarkusWelcomeResource.java. Not sure why, but there's a different class that exposes the welcome-page on Quarkus.

@stianst I adjusted the QuarkusWelcomeResource accordingly.

I just gave this a try:

With admin console and admin-api disabled --features-disabled=admin-api,admin2,admin:

Updating the configuration and installing your custom providers, if any. Please wait.
...
2022-09-02 10:15:59,178 WARN  [org.keycloak.quarkus.runtime.KeycloakMain] (main) Running the server in development mode. DO NOT use this configuration in production.

With invalid configurations like --features-disabled=admin-api and --features=admin --features-disabled=admin-api we get a lengthy stacktrace - perhaps we should just print a 1 line error message and exit.

$ bin/kc.sh start-dev --features=admin --features-disabled=admin-api             
Updating the configuration and installing your custom providers, if any. Please wait.
2022-09-02 10:17:51,966 WARN  [org.keycloak.common.Profile] (build-22) Deprecated feature enabled: admin
ERROR: Failed to run 'build' command.
ERROR: io.quarkus.builder.BuildException: Build failure: Build failed due to errors
	[error]: Build step org.keycloak.quarkus.deployment.KeycloakProcessor#configureProviders threw an exception: java.lang.RuntimeException: Invalid value for feature: ADMIN_API needs to be enabled because it is required by [ADMIN, ADMIN2].
	at org.keycloak.common.Profile.<init>(Profile.java:96)
	at org.keycloak.quarkus.runtime.QuarkusProfile.<init>(QuarkusProfile.java:28)
	at org.keycloak.quarkus.deployment.KeycloakProcessor.configureProviders(KeycloakProcessor.java:296)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
	at java.base/java.lang.reflect.Method.invoke(Method.java:577)
	at io.quarkus.deployment.ExtensionLoader$3.execute(ExtensionLoader.java:909)
	at io.quarkus.builder.BuildContext.run(BuildContext.java:281)
	at org.jboss.threads.ContextHandler$1.runWith(ContextHandler.java:18)
	at org.jboss.threads.EnhancedQueueExecutor$Task.run(EnhancedQueueExecutor.java:2449)
	at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1478)
	at java.base/java.lang.Thread.run(Thread.java:833)
	at org.jboss.threads.JBossThread.run(JBossThread.java:501)

ERROR: Build failure: Build failed due to errors
	[error]: Build step org.keycloak.quarkus.deployment.KeycloakProcessor#configureProviders threw an exception: java.lang.RuntimeException: Invalid value for feature: ADMIN_API needs to be enabled because it is required by [ADMIN, ADMIN2].
	at org.keycloak.common.Profile.<init>(Profile.java:96)
	at org.keycloak.quarkus.runtime.QuarkusProfile.<init>(QuarkusProfile.java:28)
	at org.keycloak.quarkus.deployment.KeycloakProcessor.configureProviders(KeycloakProcessor.java:296)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
	at java.base/java.lang.reflect.Method.invoke(Method.java:577)
	at io.quarkus.deployment.ExtensionLoader$3.execute(ExtensionLoader.java:909)
	at io.quarkus.builder.BuildContext.run(BuildContext.java:281)
	at org.jboss.threads.ContextHandler$1.runWith(ContextHandler.java:18)
	at org.jboss.threads.EnhancedQueueExecutor$Task.run(EnhancedQueueExecutor.java:2449)
	at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1478)
	at java.base/java.lang.Thread.run(Thread.java:833)
	at org.jboss.threads.JBossThread.run(JBossThread.java:501)

ERROR: Invalid value for feature: ADMIN_API needs to be enabled because it is required by [ADMIN, ADMIN2].
For more details run the same command passing the '--verbose' option. Also you can use '--help' to see the details about the usage of the particular command.

--features=admin --features-disabled=admin-api yields:

2022-09-02 10:17:51,966 WARN  [org.keycloak.common.Profile] (build-22) Deprecated feature enabled: admin
...
followed by the stacktrace from above

--features=admin2 --features-disabled=admin-api yields:

Stacktrace from above

@thomasdarimont Quarkus Test failures are basically about the help message. if you run HelpCommandTest you should see some files created at https://github.com/keycloak/keycloak/tree/0701922dad52e272c806ea29e24bd9faa0e89245/quarkus/tests/integration/src/test/resources/org/keycloak/it/cli/approvals/cli/help so that you can paste their content to their approved variants.

@pedroigor thanks for the hint! I just fixed the HelpCommandTest, rebased the branch and squashed the commits into a single one.

@thomasdarimont Tks.

So if I want to keep our admin dashboard separate from the public path through a reverse proxy, I'd somehow configure a subset of keycloak instances to enable the administration dashboard and some of them to disable it?

Then I would route the public facing path to the keycloak instances that have the admin dashboard disabled?

We are using the codecentric chart. Maybe the keycloak operator has better configuration to be able to do this?
https://github.com/codecentric/helm-charts/blob/keycloak-18.3.0/charts/keycloak/README.md