Repository navigation
Replies: 8 comments 8 replies
|
How is this supposed to work with multiple realms or how is auto-discovery supposed to work for individual realms then? |
|
As stated in the issue description, I understand that we should be able to discuss how to implement this, under the condition that the URL can be set on a per-realm basis. For existing realms where we want not to remove "realms/{realm}" from the endpoints, we can keep them and there should be minimum impact on existing deployments. |
|
I understand the need for this in some scenarios, but I think this should be optional. However this might actually be a quite involved change because, as mentioned before, a lot of infrastructure, libraries and framework integrations rely on a certain URL structure. However, those integrations are usually adaptable such that users can either override their behaviour or the integration may support the new way over time. Regarding the URL to realm mapping, there are multiple ways this could be achived. We could introduce a RealmNameResolver SPI which abstracts the way how the realm is resolved from a request. Based on that we could provide users with some options like obtaining the realm name from the request path (as it is now), from a URL Query parameter (non standard for .well-known) or a realm specific subdomain. Having that said, I see some benefits from supporting a "default realm" with short URLs but I also think this needs some more thoughts regarding the consequences and potential side effects. |
|
@thomasdarimont creating an abstraction makes sense to me, and would likely alleviate the transition issues. As a side note, there are multiple things to consider if this would be handled using subdomains - Keycloak (or the reverse proxy, depending on the case) would have to be able to handle multiple certificates depending on the subdomain, and that introduces other limitations (e.g., even when using wildcard certificates - which are not things all administrators appreciate, and even some CAs don't -, adding periods in the realm name would break them since That being said, I think that this change would be great, especially if a "default" domain would be supported. |
|
Thanks @darius-m yes those exactly the things I was thinking about. Wildcard certificates are one way to tackle the problem with custom subdomains (one level) with the described caveats. Another option its to add multiple SAN (subject alternative names) to the certificate instead of using a wildcard cert, which would allow for "arbitrary" hostnames / custom domains, but again introduces some administr 8000 ative overhead when a new subdomain needs to be added, but there are at least options. Deriving the realm name from a hostname fragment might also be an option, e.g.: my-realm-auth.keycloak.com, where auth.keycloak.com is the "base domain of Keycloak" and "my-realm-auth.keycloak.com" would need to be an allowed SAN in the certificate. |
|
SANs seem a bit risky, as they they immediately leak the list of domains. |
|
+1 👍 Based on our experience, we often configure Keycloak with a single realm (excluding the
This indicates that when using Keycloak as a single tenant, the current Furthermore, even when using multiple realms (e.g., providing customer environments per realm), other IDaaS solutions support custom domain feature for customer tenants. Implementing this in Keycloak with the current implementation results in the following
Therefore, I fully support this proposal. |
|
I've wanted something like this for a long time, but never come up with a decent way to implement it. One challenge is that Keycloak exposes a few resources on the base URL, not just realms:
Another is how you would configure the mapping of
Another idea was to have the concept of a default realm, so if you don't specify There's probably more challenges with this as well, but for me it never got past just briefly thinking about it and that it would be nice ;) |
|
For this to proceed someone would have to take the initiate on working on a design proposal on how this would all work. |
|
I would propose to introduce a realm domain to re-direct realm access from the domain name. It would be possible to use one certificate for the 4 domains, or we could provide an override certificate for realm1 |
|
I will note that there was just a bug fix that used the URL to determine the realm in the case where there is a 404. It wa 8000 s needed so that the error page text could be localized on a per realm basis. I consider this to be an edge case and it probably should not be a deciding factor, but wanted to make everyone aware. |
|
I would expect a check box right below the frontend url named "relative to realm". Ticking this check box means that the frontend url uniquely reaches to the current realm. Of course, the save button needs a validation that in this case the frontend url is not used for anything else, especially "/realms/master". I would be even fine if the master realm does not allow to tick the box. I can imagine that the availability of "/resources" or "/robots.txt" needs some extra rounds of thinking. |
|
Marking as closed to move the conversation and refinement to #14623 |
Uh oh!
There was an error while loading. Please reload this page.
Benefits:
Simply deleting "realms/{realm}" simplifies the endpoint URL and allows us to closely comply with RFC5785, for example. RFC5785 expects "/.well-known/" to be located directly under authority, but Keycloak does not comply with this.
If "realms/{realm}" is included in the URI, attackers can tell that Keycloak is being used. By removing "realms/{realm}" from the URI, it becomes more difficult for an attacker to easily determine that Keycloak is being used.
Idea of implementation:
All reactions