Repository navigation
Replies: 17 comments 30 replies
|
Thank you all for this update! We definitely belong to use-case "SaaS" and are very interested in the storage changes, which will hopefully remove the limit on number of realms. |
|
The limitations on number of realms will for sure go away, we're also looking at some form of multi-tenancy/customers within a realm. Details on that is still to be worked out though, so stay tuned. |
This would be a really nice feature |
|
Thank you for the news regarding Keycloak.X. One problem with the current Keycloak distribution is that zero downtime upgrades are not possible. Is there any information yet if and how zero-downtime upgrades are possible in Keycloak.X? In the blog post, this item appeared under Storage re-architecture. |
|
Zero-downtime upgrades will be available in the new storage as mentioned in the blog post, which also mentions the roadmap for that. |
|
We're very excited about Keycloak X! We're running Keycloak in Kubernetes now, and we've run into a few problems. I have a wishlist of Keycloak features around running in Kubernetes:
I don't want these to sound like complaints. We're happy with Keycloak in general. And it sounds to me like Keycloak X will help with most of these issues. Thanks so much! |
|
Hi, Providing a theme without extending the Image is possible. Basically you mount an empty volume into keycloak's theme-folder and fill it via init-container. See the Codecentric Keycloak Helm-Chart for an explanation. |
|
Hi, We're very keen to move to Keycloak.X distribution but IMHO there is a lake of a comprehensive documentation on how to migrate (e.g. how to convert custom startup cli that manipulate Wildfly xml-based configuration files) ? Regards, |
|
Could you provide some more details on what you're thinking about? In general it will be very hard to provide any direct migration as everything is configured very differently. In addition Keycloak.X aims to be significantly easier to configure and have much better and opinionated defaults. |
|
Hi,
All these cli were built based on keycloak documentation or examples from the community. We'd like to found the same kind of guidance for Keycloak.X. For instance, how to configure logging, cache , event listeners ... Regards, |
We are also doing that when running the server in dev mode.
We have options only for server proxy settings. We lack http client proxy settings ... Can you tell us what you are using so we can try to make them more explicit in our CLI?
We are still figuring out how that should look like. Could you please share your experiences at #8870?
We have now basic options to choose a config file + set the transport stack. We can do much more here such as allow setting the number of owners, etc. But I'm not sure whether this should be just a matter of updating/creating your clustering config files or if it makes sense to provide specific options. Can you share what you are using?
Do you mean deploy a provider?
Shall we make this disabled by default?
it should be possible to do that now by using a specific option. |
|
Regarding :
see https://www.keycloak.org/docs/latest/server_installation/#_proxymappings for configuration/subsystem=keycloak-server/spi=connectionsHttpClient/provider=default:write-attribute(name=properties.proxy-mappings,value=${env.PROXY_MAPPING})
here is the cli we're using: Add date to timestamp field in colored logs/subsystem=logging/pattern-formatter=COLOR-PATTERN:write-attribute(name=pattern, value="%K{level}%d{yyyy-MM-dd HH:mm:ss,SSS} %-5p [%c] (%t) %s%e%n") Configure log level/subsystem=logging/logger=com.example.myidp:add
Mainly to workaround a bug in KC 14.0.0 and to enable cache metrics ` Avoid Memory leak from KC (https://github.com/keycloak/keycloak/pull/8215/files)Add expiration lifespan configuration to every distributed and replicated cache.echo Setting expiration lifespan for 'work' replicated-cache echo Enable cache metrics
` Configure events listeners/subsystem=keycloak-server/spi=eventsListener:add Enable event logging/subsystem=keycloak-server/spi=eventsListener/provider=jboss-logging:add(enabled=true) Propagate success events to INFO instead of DEBUGThis allows to track successful logins in log analysis/subsystem=keycloak-server/spi=eventsListener/provider=jboss-logging:write-attribute(name=properties.success-level,value=info) Configure my-event-listener event listener/subsystem=keycloak-server/spi=eventsListener/provider=my-event-listener:add(enabled=true) Configure key cache/subsystem=infinispan/cache-container=keycloak/local-cache=keys/component=expiration:write-attribute(name=lifespan, value=${env.KEY_CACHE_LIFESPAN:86400000}) `
IMHO , yes , this should be the default configuration since restarting keycloak w/ millions offline sessions in the DB takes too much time. |
|
While I appreciate the move to Quarkus and all the related stuff, even is some hard work is coming to some of us in heavily customized environments, I want to emphasize, that there are also a lot of users/customers who are using Keycloak deployed in a "legacy" standard way of doing this like "bare metal" and also running in container but not on K8s. |
|
We are, and Keycloak.X is by no means K8s specific |
|
What exactly should "headless" mean? I'd welcome the former. |
|
Really interested about Keycloak.X . I have installed KeyCloak in a couple of VMs without k8 or docker, since I'm not interested, so I hope the next versions of KC will be still supported in a "legacy" environment. |
|
https://github.com/LuciferSam86
Seems you hijacked a thread on "headless" - but yes it will not be K8 only for sure |
|
"Headless" is still to be defined, but yes the use-case is to customize the central IdPs UI, not to embed into applications. |
|
My personnal wishlist for Keycloak future :
|
|
Where is the source for Keycloak.X? I've looked everywhere I can think, but I don't see it. I have a number of rather specific extensions, and I wanted to see if they would work. If I have to debug them, I'd need the source of the server. Thanks! |
|
github.com/keycloak/keyloak 😉 |
|
Ah, the main branch is Keycloak.X? I'd have thought you would have opened a new repo to keep the projects separate. Perhaps you could add a tag or do something to make it more clear? Just looking at the README for the main repo doesn't say anything about Keycloak.X, so I figured it would only contain code for the legacy project. |
|
how does the Keycloak -> Keycloak.X migration path look like? I'm asking because we were about to go live with the old Keycloak distribution because the Keycloak.X distribution didn't look production ready at all(seeing no updates in about 1 year) and now we're essentially told that the old version is being deprecated in 3/6 Months. Other than that I Like the improvements that keycloak.x is promising! |
|
The Quarkus distribution is the first thing that is coming, which is in December/January it will be final. The database will be unchanged at this point, so you only need to change how you install and configure it to switch to the Quarkus distribution. You have 6 months to do that, or Red Hat Single Sign-On will allow you to continue without any changes until June 2024. |
|
We are using Red Hat Single Sign-On (RH-SSO), but always keeping an eye on what happens to Keycloak, as we're expecting that new features are also always coming to RH-SSO in a few months time. Therefore it is worrying me that you are saying RH-SSO stays without changes until June 2024, @stianst There are features already in Keycloak, which didn't make it to 15.0.2 and therefore not to RH-SSO 7.5 (for example the EncryptedID in SAML Responses) and we are waiting for a bigger contribution around the SAML Parser in the Identity Brokering. But will these features reach RH-SSO 7.x soon or only RH-SSO 8 or do we even have to wait until June 2024? That would be a catastrophy and we would have to consider switching from RH-SSO to Keycloak... |
|
@rowe42 RH-SSO 7.y stays as it is with regard to WildFly and the old store. Other features will be included in RH-SSO 7.6. Quarkus and the new store will come in RH-SSO 8 (dates tbd). |
|
Hi and thanks for blog post about Keycloak.X. I really love the idea of a modern Keycloak distribution. So can you please clarify some questions about extensions in the future? One example use case we have is an approval workflow to add users to groups. My current approach is to build an extension with custom rest endpoints, entities and so on in Keycloak. Reading the blog post if sounds like this is not the way in the future. Should we even follow this path anymore or is it better to have some kind of external sidecar application using the REST API without integration with Keycloak directly? One other issue is the new storage layer. Does this refer to the underlying database or are changes to the model also possible here? Other than that, thank you very much for your work. I look forward to the next releases. |
|
First of all thanks guys, Keycloak rocks! Here some points which can be improved:
This are just some ideas we wanted to share and thank you for this awesome project. BR Mehmet |
|
@marziman regarding this:
couldn't you use vault sidecar (ie pseudo mount) + file based secrets? Note. I am not a big fan of the sidecar approach but just suggesting |
|
@trixpan Thank you for the feedback!
@stianst is preparing a "framework" for building our docs and we should have something better for sure. It sucks today, yeah. We are also trying to make CLI and default configuration as helpful as possible to configure/deploy the server.
Would you be able to share your experience scaling Keycloak so that we can think about including/changing our defaults in terms of: clustering, database connections, HTTP settings (timeout, io/worker threads), security (vault, etc)?
We are now enabling mounted secrets (similarly to Wildfly distribution) and also Hashicorp integration by leveraging the
That is what we are trying to achieve. Right now we have The same goes for clustering. For instance, clustering now is by default based on Infinispan default stacks for ec2, azure, google, k8s, etc. It is a matter of picking one and setting its properties. We still have to improve here in terms of UX.
We have @thomasdarimont working on that. |
|
@pedroigor actually those been our feedbacks :-) We are more than happy to contribute. |
|
I have been testing keycloak-x (using 15.0.2 but also observing changes in master) and noticed a few distinctive changes in behaviour between X and legacy.
Not a change in behaviour but worth of note:
Bugs:
|
|
The EAR deployments is not something we can support with Quarkus for sure, so will have to be single JARs. However, each JAR can of course contain multiple providers. Not sure it is possible to support keys changing at runtime. At the very least I would think the http listeners would need to be restarted, and by then you're quite close to having to restart Keycloak anyways. We're optimising more and more the startup time for Keycloak, so perhaps this is good enough. <- @pedroigor @DGuhr FIY. With Keycloak 16 kc.sh will behave quite differently and there are loads of improvements being made, and there is now a more clear definition between "build" and "runtime" configuration, where things like changing the DB vendor is a build time option, which to be able to get the best startup you should extend the image with build time config. There's also a "--auto-build" option though, and this is how the base image we deliver will behave, so it will take into account the updated DB vendor. |
|
@trixpan First of all, thanks for the helpful feedback. We really need this to make sure we are moving to the right path. I second @stianst comments. I would just add:
We really appreciate if you can try out the upstream version. |
|
I'm curious if it will be possible to easily run Keycloak.X on GCP Cloud Run. I was trying to run Keycloak on it but because of wildfly and some background job it was not possible at all. |
|
@Mistic92 The same background jobs still exist. Perhaps it makes more sense to open an issue for this one. |
|
Please confirm if defining security policy within a realm will also be more flexible in Keycloak.X e.g. defining different password expiry for users within a realm . thanks in advance. |
|
@c-piyush Keycloak.X is basically the same distribution in terms of IAM functionality. However, you should expect UX improvements from the new admin console. |
|
My primary wish would be for the team to focus on headless UI. I think customizing the UI is one of the first things most new Keycloak users do, because most of the other deployment and configuration for Keycloak has sensible defaults. But often they may be overwhelmed by the theme options or Keycloak themes may just not fit with their workflow (eg if they're using a library like React's Chakra UI or Tailwind CSS, and they have all their design tokens/components in that framework, and they would have to extract those styles from those tools and learn Keycloak-specific css classes like I think eventually exposing all the internal Keycloak auth page APIs as REST with JSON, with good documentation, would allow users to use a totally different framework like React, Vue, etc, to render the auth pages. Then either the Keycloak binary could serve this custom auth UI Single Page App, or the user could deploy it with a normal server like NGINX or as a static site using a CDN. Thanks for all the great work and the vision for Keycloak.X! |
|
As the original author of Keycloakify I fully agree with this comment. |
|
Hi All, we appreciate if you can look at what we are planning in terms of documentation so that you can help us to cover the main aspects of the new distribution and how to use it to configure and start Keycloak. Please, leave your comments here #9034. |
|
Hi, We have multiple Wildfly-bsaed instances on Postgres that have been running for years that are now on the quay.io/keycloak/keycloak:17.0.1-legacy tag. We are really confused about migrating to the regular 17.0.1 release for moving forward, as we aren't wanting to compile our own instances right now. Ideally I'd just like to run pre-built images with a Postgres driver baked in, as opposed to having to rebuild our own image for every release. The "Migrating to Quarkus" page (https://www.keycloak.org/migration/migrating-to-quarkus) says "..there is also an auto build mode that makes Keycloak behave more or less the same as the WildFly distribution in this regard", but doesn't explain how to do that. How do we do that? :) Thanks! |
|
@preston The auto-build mode is enabled by passing the It will trigger a |
Uh oh!
There was an error while loading. Please reload this page.
We would love general feedback on our plans around Keycloak.X.
All reactions