Repository navigation
implement wildcard hostnames - #14118
silviokennecke wants to merge 3 commits into
Conversation
For security reasons validRedirect values containing only a wildcard for the hostname should not be allowed.
There was a problem hiding this comment.
Thanks for the PR, but we do not want to open redirect-uris more without it being configurable through client policies. Please see #9278 for more details.
If you are interested in looking at that let us know and we can discuss how to proceed.
|
Thanks for the feedback. I’ll have a deeper look into it and see if I will implement the client rules for that. |
|
Found this PR (haven't looked at it in detail yet) that may be relevant: |
|
@stianst Do you know the current status of the PR? It's open since 2021 and labeled for needs discussion. From what I see (didn't tested it yet), it would solve the issue you put this pr on hold for. In the discussion, I also found agreement of many, that wildcard hostnames should be allowed in the end. |
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
|
@silviokennecke Thanks for the contribution and sorry it took so long to review. I am closing as this was already addressed by #25637, which has some additional flexibility and should be available in Keycloak 24. |
|
is it really addressed by #25637 ? see discussion in #9278 (reply in thread) |
Actually not adressed in KeyCloak 24 |
|
@mposolda closed by mistake? |
|
Why was this closed ? Did the reviewers actually review this ? They said it was addressed but that couldn't be further from the truth. |
|
It was closed allegible because it was addressed by #25637 . But that seems to be a mistake. Read #9278 (reply in thread) . But none of the maintainers seem to read this 😉 |
|
Maybe doing a new PR with the same content would make them notice |
|
The client profile executor both limits the hostnames that can be used when creating redirect URIs on the client as well as validates the redirect URI on inbound calls. That being the case I first set a redirect URI of 'https://*' on my client and then set an allow permitted domain of With these settings in place I am able to use a redirect URI of https://subdomain.example.com/auth but not https://subdomain.otherdomain.com/auth. Now my issue is that I have my Web Origins set to '+' which copies the values from redirect URIs and strips off the trailing wildcard. That means that my redirect URI of 'https://*' becomes a Web Origin of 'https://' which does not match my actual redirect URI that I am using 'https://subdomain.example.com' and fails CORS in the browser. If I change the Web Origins from All being said, I would say that the redirect URI issue has been solved for me, but the way it was solved introduces a Web Origins issue. |
|
I still seem to be having the problem with Keycloak 25. Cannot use wildcards in hostnames. Basically, I want to be able to use |
|
I think it should be added but docs should discourage it on production systems. It is very useful in development environments though. |
|
It's not only useful for testing systems. We have an internal service that listens on 30+ different subdomains, each running the same SPA but for different projects or working groups. Those instances change regularly and new instances can be created on demand. Not sure if it is possible to edit redirect URLs in a client config, or add new clients, programmatically. But even if that would be possible, managing those and keeping everything in sync would be really annoying. We currently have a workaround in place where the user would be redirected to |
So this is what I landed up eventually doing. We have a "review" realm, and spin up review applications, each on their own domain. As part of the deploy to a review environment, we programatically add that new env's callback url via KC's API. We also clean it up when we tear down the environment. It was a minor pain to implement. If you've integrated into KC's API before, it's relatively simple. We used this amazing ruby client to get it done. |
I think it can be done via Keycloak admin API, we do such things via Terraform for example. |
If you run your own Keycloak just for a single project, sure. But not if you are authenticating against a Keycloak that's managed by a different team and you have to write support tickets to change client settings. Chaining Keycloaks would be an option, sure, but I really do not want to run and maintain my own Keycloak and build integrations scripts that fiddle with the Admin API just because Keycloak does not support wildcards in URL subdomains :/ |
I second that perspective. We operate a cloud platform that enables users to create and manage services with flexible durations, whether temporary or long-term, all accessible via subdomains on *.our-domain.com. The platform employs a single-level wildcard certificate, ensuring secure connections across all hosted services within this domain structure. |
|
If you have open clients you have to be extremely careful with redirects so probably this is the cause wildcards are not supported as we wish here. In our case we wanted to use them only in Keycloak instance with restricted network access. I would never use wildcards in redirects configured in a public keycloak instance anyway as it may impose serious security issues. |
Could you explain? How are wildcards on subdomain-level a security risk? "Because it could be used to configure insecure clients" is not a really convincing argument. With that logic, many other config options would also have to be permanently disabled. The people configuring clients usually know what they are doing. Currently, the only alternative is to give developers access to the Admin API, which sounds a lot worse to me. |
|
Wildcards on subdomain-level a security risk? Right, because forcing a full wildcard to achieve the goal it sooo much safer. Keycloak is a tool to achieve a goal. Don't get in the way. It's fine to add a warning to say that a client is not compliant etc. Or allow it as an advanced flag. But it simply must be allowed, that part is not up for discussion. How to best implement it can be discussed. |
This PR extends
org.keycloak.protocol.oidc.utils.RedirectUtils#matchesRedirectsto allow wildcards in the hostname of valid redirect URIs.https://*.my-domain.com/my-redirecthttps://dev.my-domain.com/my-redirectfalsetruehttps://*.my-domain.com/my-redirect/*https://dev.my-domain.com/my-redirect/some-idfalsetruehttps://dev-*.my-domain.com/my-redirecthttps://dev-my-ticket.my-domain.com/my-redirectfalsetruehttps://dev-*.my-domain.com/my-redirect/*https://dev-my-ticket.my-domain.com/my-redirect/some-idfalsetruehttps://live.my-domain.com/my-redirecthttps://live.my-domain.com/my-redirecttruetruehttps://live.my-domain.com/my-redirect/*https://live.my-domain.com/my-redirect/some-idtruetruehttps://dev-*.my-domain.com/my-redirecthttps://live-not-dev-my-ticket.my-domain.com/my-redirectfalsefalsehttps://live.my-domain.com/my-redirecthttps://not-live.my-domain.com/my-redirectfalsefalsehttps://*/my-redirecthttps://dev.my-domain.com/my-redirectfalsefalsehttps://*:8443/my-redirecthttps://dev.my-domain.com:8443/my-redirectfalsefalsehttps://*:*/my-redirecthttps://dev.my-domain.com:8443/my-redirectfalsefalsehttps://live.my-domain.com:*/my-redirecthttps://live.my-domain.com:8443/my-redirectfalsefalseDiscussion
No discussion was opened in advance to this change. But there are discussions related to this, which can be found in the issue.
The related issue is #14113.
Documentation
The relevant tooltip for the UI has been updated.
Testing
A testing of the updated method was done. Because no existing tests for
matchesRedirects(or it's caller) were not found, no additional unit tests were written. The tested cases are described above.Security impact
The official OpenID Connect specification recommends, only checking with strict string comparison. While this is totally applicable for production environments, users/companies with multiple environments (for instance staging, testing, dev, etc.) often disturbed by this. This especially applies for instance when a staging system is created for every PR, serving under a different domain (like
https://stage-<ticketId>.my-domain.com). To prevent users allowing all hostnames (https://*/redirect), a check has been added.