Replies: 5 comments 10 replies
-
Beta Was this translation helpful? Give feedback.
-
|
When the admin UI is exposed on a different URL it needs to know the URL of the admin UI to link to it also to have the admin clients configured correctly. How would you do that without |
Beta Was this translation helpful? Give feedback.
-
@shawkins Could you please explain a bit more what you mean here and give a few examples? I'm trying to understand if this approach helps in configuring Keycloak in such a way that you can separate admin traffic (that typically goes to the |
Beta Was this translation helpful? Give feedback.
-
|
@stianst @slaskawi let me see if I can answer both of your questions together. With hostname-admin we currently support:
Without hostname-admin things look like:
Comparison:
This seems to be more regular than having just a single global hostname-admin, however I may be missing some of the original requirements behind hostname-admin. For example were there plans to eventually support hostname-admin on a per realm basis, or is it generally not possible to expect users / proxies to do access restrictions based upon something other than the hostname? |
Beta Was this translation helpful? Give feedback.
-
Because you would need to do that for every realm. Each realm potentially has its own admin console, and I reckon the user wants to restrict the access to all of those, not just the master realm admin console. |
Beta Was this translation helpful? Give feedback.
-
To work with your example: --hostname would remain https://sso.uds.dev The master realm would have its front-end url set to https://keycloak.admin.uds.dev, and hostname-admin would be unset.
This is where there is a difference.
What's not clear to me about why hostname-admin is desirable in this situation:
They don't really have their own admin console - there's a global hostname admin - the differentiation is path based and you already need to account for restricting access to /admin in the proxy. |
Beta Was this translation helpful? Give feedback.
-
Sorry, I was not clear. I meant the case when you'd wanted to expose all admin consoles on a hostname that is different from the front-end. This wouldn't be possible without hostname-admin. |
Beta Was this translation helpful? Give feedback.
-
Agreed, and I'm trying to understand if that is hard requirement and/or why we don't support a hostname-admin per realm. Based upon #14623 and similar requests, I'd say that for both front-end and admin traffic to the proxy we'd want the path containing the realm to be optional. |
Beta Was this translation helpful? Give feedback.
-
To understand a bit better - in what cases does the server need to enforce a specific admin hostname, or can that be up to the proxy? Let's say for example that we had a setting like If I wanted to require a specific hostname for a particular realm's admin console could that be done via the security-admin-console client's root url? |
Beta Was this translation helpful? Give feedback.
-
|
Discussed this more with the cloud native team - and the short answer is that we want to keep a single default hostname-admin for all realms. It seems uncommon for users to want a hostname per realm for administration - this was moved to it's own topic #47457 should we want to move that forward. #47453 discusses how we can leverage the hostname admin to further enforce what traffic is allowable from proxies. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Users are already expected to do path based access restrictions for /admin
Users commonly, and mistakenly, believe that just setting the hostname-admin should allow access to be blocked to front-end/realms/master (most recently discussed on #42264 - it seems that the admin console logic previously may have been using hostname-admin/realms/master).
Having just a global hostname-admin is also problematic because we'll eventually need a per-realm hostname-admin setting to support a more complete tenant model.
It seems cleaner moving forward to deprecate the concept of hostname-admin and just rely on the path based access restrictions and realm based front-end URL settings.
cc @keycloak/cloud-native @slaskawi
Beta Was this translation helpful? Give feedback.
All reactions