fidzu : JBoss

10 Mar 2025 6:11pm GMT

We are thrilled to announce that Keycloak will be at KubeCon Europe, London April 1-4th 2025. Keycloak's presence at previous KubeCons was a huge success, and we are always eager to meet Keycloak enthusiasts, users and newcomers alike. At this year's event we will be hosting a Kiosk in the Project Pavilion, as well as presenting a talk about Evolving OpenID Connect and Observability. KEYCLOAK COMMUNITY MEET & GREET AT THE PROJECT PAVILION from Hitachi, and from Red Hat, and other contributors will be hosting a Keycloak kiosk at the . This is a great chance to meet people who use Keycloak, contribute to Keycloak, take our survey about new Keycloak features, and get some cool swag! Keycloak Kiosk opening hours: * Wednesday, April 2: 15:30 - 19:45 * Thursday, April 3: 14:00 - 17:00 * Friday, April 4: 12:30 - 14:00 PRESENTING EVOLVING OPENID CONNECT AND KEYCLOAK OBSERVABILITY and will be presenting a talk on Evolving OpenID Connect and Observability in Keycloak. * Friday, April 4, 14:30 - 15:00pm By Takashi Norimatsu, Hitachi & Ryan Emerson, Red Hat. RELATED TALKS Keycloak has a powerful community in Japan, and we have received several contributions in the past. One of Keycloak's maintainers, Takashi Norimatsu, is based in Japan. There is also a quite popular Japanese book about by Yuichi Nakamura and Japanese community colleagues that will soon appear in its second edition. To learn more about community activities in Japan, join the following talk: * Thursday April 3, 2025 14:15 - 14:45 By Ota Kohei, Apple; Shu Muto, NEC Solution Innovators, Ltd.; Yuichi Nakamura, Hitachi, Ltd.; Sunyanan Choochotkaew, IBM Research; Noriaki Fukuyasu, The Linux Foundation SEE YOU SOON! We're preparing for KubeCon EU 2025 and can't wait to connect with our community. Mark your calendars and join us. See you in London!

08 Mar 2025 12:00am GMT

Recently we blogged about testing WildFly on Docker effectively and easily, thanks to Arquillian Cube, now it's time to make it Kubernetes! In the article we saw how an Arquillian Cube test can be implemented to automate the build and execution of a Docker image that contains a WildFly deployment, and to run tests against it. This time we'll see how a very similar process can be used to set up an automated integration test for a WildFly application that should instead be run on Kubernetes. Our goal is to provide an automated solution to replace the final part of the guide. USE CASE The guide uses an existing Docker image, pushes it to Quay.io, and then shows how to create Kubernetes resources, namely a Deployment that manages the WildFly application workload, and a NodePort type Service that exposes it externally. That's cool!… but still, it is based on manual steps. In order to automate this, we'll modify the example application that we showcased in , to add a JUnit test, powered by Arquillian Cube, that will automate the Kubernetes resources creation, starting from existing YAML definitions, and use APIs and annotations at the test class level. STEP BY STEP CHANGES As said, we will to start from the article, so make sure to go through it, and maybe create a separate Git repo, or branch if you want to keep working on both examples, then… KUBERNETES RESOURCES DEFINITION Let's copy/paste the YAML definition which is used in into a kubernetes.yaml file, that we'll place in our project test/resources folder. We'll modify the Deployment name, but it is basically the same as the one in the guide: apiVersion: apps/v1 kind: Deployment metadata: name: my-jaxrs-app-deployment labels: app: my-jaxrs-app spec: replicas: 1 selector: matchLabels: app: my-jaxrs-app template: metadata: labels: app: my-jaxrs-app spec: containers: - name: my-jaxrs-app image: quay.io/tborgato/my-jaxrs-app ports: - containerPort: 8080 - containerPort: 9990 livenessProbe: httpGet: path: /health/live port: 9990 readinessProbe: httpGet: path: /health/ready port: 9990 startupProbe: httpGet: path: /health/started port: 9990 Then - similarly to what is manually done in the WildFly miniseries guide - let's add a Kubernetes Service resource definition, by appending it to the same file. Here as well, we'll use a meaningful name: apiVersion: v1 kind: Service metadata: name: my-jaxrs-app-service spec: ports: - port: 80 protocol: TCP targetPort: 8080 selector: app: my-jaxrs-app The whole kubernetes.yaml file will now look like this: apiVersion: v1 kind: Service metadata: name: my-jaxrs-app-service spec: ports: - port: 80 protocol: TCP targetPort: 8080 selector: app: my-jaxrs-app --- apiVersion: apps/v1 kind: Deployment metadata: name: my-jaxrs-app-deployment labels: app: my-jaxrs-app spec: replicas: 1 selector: matchLabels: app: my-jaxrs-app template: metadata: labels: app: my-jaxrs-app spec: containers: - name: my-jaxrs-app image: quay.io/tborgato/my-jaxrs-app ports: - containerPort: 8080 - containerPort: 9990 livenessProbe: httpGet: path: /health/live port: 9990 readinessProbe: httpGet: path: /health/ready port: 9990 startupProbe: httpGet: path: /health/started port: 9990 and, rather than applying it manually to our Minikube instance via a kubectl command, we'll let Arquillian Cube do the job! Specifically, Arquillian Cube provides several ways to automate your Kubernetes tests - including a - but we'll use the most common approach in this example, i.e. using a _kubernetes.yaml definition in the classpath. If such a definition exists, then Arquillian Cube will apply it to the cluster, and it will provide us with APIs and annotations at the class level that we'll use to wire the test logic up, as we'll see later on. UPDATE THE EXAMPLE PROJECT POM A few changes, provided we started from the previous article about . The first thing we need to do is to add a couple more properties for two new dependencies that we'll need to add; details are explained later: 6.9.2 1.3.33.Final 6.2.11.Final Then, in order to make our project POM more readable, we should remove the code that we commented out , so let's start by removing the following block in the section, i.e.: then, let's remove the commented out fragments in the / section: Done with removals. Now, onto the dependencyManagment section, which also contains a definition of the wildfly-ee BOM, used in . We can comment that out now: Let's move to the dependencies section, where we'll first comment the Jakarta EE dependencies out: The next one is quite important from the Arquillian perspective: we'll replace the dependency from the Arquillian Cube Docker extension with the Arquillian Cube Kubernetes extension, so we'll keep the following commented out block in the example sources for clarity: org.arquillian.cube arquillian-cube-kubernetes test org.arquillian.cube arquillian-cube-kubernetes-starter test io.fabric8 kubernetes-client ${fabric8.kubernetes-client.version} test io.undertow undertow-core ${undertow-core.version} test As you can see we added the arquillian-cube-kubernetes-starter and kubernetes-client dependencies, too. The former is needed to let Arquillian Cube automatically start the Kubernetes "container" (broader meaning here). The latter provides us with all the Kubernetes APIs, which we'll use in the test class, as we'll see below. We had to lock the undertow-core dependency version too, since we need one that is compatible with Arquillian Cube 2.0. Let's remove the following JBoss Logging dependency, as it will not be used: One last thing in the test dependencies section, let's give a version to the RESTEasy client dependency, since we removed the wildfly- ee BOM from the dependencyManagment section: org.jboss.resteasy resteasy-client ${resteasy-client.version} test Now, onto the / section. First off we don't need for the maven-clean-plugin to clean up any Docker files; in fact we'll remove those from our project sources later on, since this test will not build nor run any Docker images. Let's comment the section as follows: Then we should remove the WildFly Maven plugin definition, too, as this a Kubernetes test, which will rely on an image that is deployed to Quay.io already, as per the original example. Let's comment the whole plugin configuration out: Finally, let's comment the following section properties, too, since they're no longer relevant nor used: and similarly with the JUnit 5 related property, since we're using JUnit 4: And that's it, we're done with the POM, and feel free to check your version against the example sources on GitHub, where you can find a version, too. Let's get to the arquillian.xml file now, and see how should be modified. UPDATE ARQUILLIAN.XML CONFIGURATION A simple update will do, start by removing or commenting the docker extension part out: easy, we don't need a wildfly container anymore, so let's remove it, and add a kubernetes extension declaration, which we'll keep empty. The last part is about the test class itself, let's dive in… REMOVE THE APPLICATION SOURCES Again, we're not building any application here. We rely on a Docker image on Quay that contains the application already; therefore we don't need the application sources, which can be safely removed: $ rm -rf src/main/java/org $ rm -rf src/main/webapp CREATE A TEST CLASS FOR TESTING ON KUBERNETES We must actually delete the existing Docker test, first: $ rm src/test/java/org/wildfly/examples/GettingStartedDockerIT.java and - as anticipated previously, we'll now remove the Docker related resources, too: $ rm -rf docker-build $ rm docker-compose.yml There we go, now it's time to create a new GettingStartedKubernetesIT.java class, with the following contents: package org.wildfly.examples; import io.fabric8.kubernetes.api.model.Service; import jakarta.ws.rs.client.Client; import jakarta.ws.rs.client.ClientBuilder; import jakarta.ws.rs.core.Response; import org.arquillian.cube.kubernetes.annotations.Named; import org.arquillian.cube.kubernetes.annotations.PortForward; import org.jboss.arquillian.junit.Arquillian; import org.jboss.arquillian.test.api.ArquillianResource; import org.junit.Assert; import org.junit.Test; import org.junit.runner.RunWith; import java.net.URISyntaxException; import java.net.URL; import static junit.framework.TestCase.assertFalse; import static org.junit.Assert.assertNotNull; /** * Run integration tests on Kubernetes with Arquillian Cube! */ @RunWith(Arquillian.class) public class GettingStartedKubernetesIT { @Named("my-jaxrs-app-service") @ArquillianResource private Service myJaxrsAppService; @Named("my-jaxrs-app-service") @PortForward @ArquillianResource private URL url; @Test public void shouldFindServiceInstance() { assertNotNull(myJaxrsAppService); assertNotNull(myJaxrsAppService.getSpec()); assertNotNull(myJaxrsAppService.getSpec().getPorts()); assertFalse(myJaxrsAppService.getSpec().getPorts().isEmpty()); } @Test public void shouldShowHelloWorld() throws URISyntaxException { assertNotNull(url); try (Client client = ClientBuilder.newClient()) { final String name = "World"; Response response = client .target(url.toURI()) .path("/hello/" + name) .request() .get(); Assert.assertEquals(200, response.getStatus()); Assert.assertEquals(String.format("Hello '%s'.", name), response.readEntity(String.class)); } } } As you can see, the test didn't change much from the one in the example: we verify that the service - which is implemented by a Kubernetes workload - returns HTTP 200 and the expected response body when it is called via its URL. And that is where Arquillian Cube comes in handy because, thanks to it, we could inject such a URL in our test class url field just by using an annotation. Similarly, we have injected an io.fabric8.kubernetes.api.model.Service instance which represents the Kubernetes service resource that we Arquillian Cube creates based on the kubernetes.yaml definition. RUN THE TEST That's it, we can run our Kubernetes integration test. Arquillian Cube will use the information stored in the ~/.kube/config file to connect to a Kubernetes cluster, or . For this example, starting a instance will be enough: minikube start and then issue the following command: mvn clean install and we'll see how Arquillian Cube will gather the kubernetes extension configuration, then summarize the container definition, trace the resources creation on the cluster, and eventually run the test: [INFO] ------------------------------------------------------- [INFO] T E S T S [INFO] ------------------------------------------------------- [INFO] Running org.wildfly.examples.GettingStartedKubernetesIT ... CubeKubernetesConfiguration: namespace = itest-4d12b880 master.url = https://192.168.39.213:8443/ namespace.lazy.enabled = true namespace.cleanup.enabled = true namespace.cleanup.timeout = 0 namespace.cleanup.confirm.enabled = false namespace.destroy.enabled = true namespace.destroy.confirm.enabled = false namespace.destroy.timeout = 0 wait.enabled = true wait.timeout = 480000 wait.poll.interval = 5000 ansi.logger.enabled = true env.init.enabled = true logs.copy = false cube.api.version = v1 cube.trust.certs = true cube.fmp.build = false cube.fmp.build.disable.for.mvn = false cube.fmp.pom.path = pom.xml cube.fmp.debug.output = false cube.fmp.logs = true Initializing Session:4d12b880 Using Kubernetes at: https://192.168.39.213:8443/ Creating namespace: itest-4d12b880... To switch to the new namespace: kubectl config set-context `kubectl config current-context` --namespace=itest-4d12b880 Applying kubernetes configuration from: file:/home/fburzigo/Projects/git/fabiobrz/wfly-mini-k8s-cube/getting-started/target/test-classes/kubernetes.yaml ReplicaSet: [my-jaxrs-app-deployment-56bbc54bf9] Pod: [my-jaxrs-app-deployment-56bbc54bf9-zsc2m] Status: [Running] Service: [my-jaxrs-app-service] IP: [10.111.189.164] Ports: [ 80 ] Jan 31, 2025 4:49:45 PM org.arquillian.cube.kubernetes.impl.resources.KubernetesResourcesApplier applyKubernetesResourcesAtClassScope INFO: Creating environment for org.wildfly.examples.GettingStartedKubernetesIT Jan 31, 2025 4:49:45 PM org.arquillian.cube.kubernetes.impl.resources.KubernetesResourcesApplier applyKubernetesResourcesAtMethodScope INFO: Creating environment for org.wildfly.examples.GettingStartedKubernetesIT method shouldShowHelloWorld Jan 31, 2025 4:49:45 PM org.xnio.Xnio INFO: XNIO version 3.8.16.Final Jan 31, 2025 4:49:45 PM org.xnio.nio.NioXnio INFO: XNIO NIO Implementation Version 3.8.16.Final Jan 31, 2025 4:49:46 PM org.jboss.threads.Version INFO: JBoss Threads version 2.4.0.Final Jan 31, 2025 4:49:46 PM org.arquillian.cube.kubernetes.impl.resources.KubernetesResourcesApplier removeKubernetesResourcesAtMethodScope INFO: Deleting environment for org.wildfly.examples.GettingStartedKubernetesIT method shouldShowHelloWorld Jan 31, 2025 4:49:46 PM org.arquillian.cube.kubernetes.impl.resources.KubernetesResourcesApplier applyKubernetesResourcesAtMethodScope INFO: Creating environment for org.wildfly.examples.GettingStartedKubernetesIT method shouldFindServiceInstance Jan 31, 2025 4:49:46 PM org.arquillian.cube.kubernetes.impl.resources.KubernetesResourcesApplier removeKubernetesResourcesAtMethodScope INFO: Deleting environment for org.wildfly.examples.GettingStartedKubernetesIT method shouldFindServiceInstance Jan 31, 2025 4:49:46 PM org.arquillian.cube.kubernetes.impl.resources.KubernetesResourcesApplier removeKubernetesResourcesAtClassScope INFO: Deleting environment for org.wildfly.examples.GettingStartedKubernetesIT [INFO] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 15.05 s -- in org.wildfly.examples.GettingStartedKubernetesIT Deleting namespace: itest-4d12b880... Namespace: itest-4d12b880, successfully deleted Destroying Session:4d12b880 [INFO] [INFO] Results: [INFO] [INFO] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0 ... [INFO] ------------------------------------------------------------------------ [INFO] BUILD SUCCESS [INFO] ------------------------------------------------------------------------ [INFO] Total time: 18.281 s [INFO] Finished at: 2025-01-31T16:49:47+01:00 [INFO] ------------------------------------------------------------------------ IN CONCLUSION Testing a WildFly application directly on Kubernetes will make the test more effective, and will allow prototyping and make debugging easier. Arquillian Cube provides an easy and effective way to test on Kubernetes, with almost no configuration and instrumentation changes with respect to existing Arquillian based tests. The code for the example application which is described in this article is here: Fabio Burzigotti

06 Mar 2025 12:00am GMT

Hi, Red Hat announced significant changes to its middleware strategy last month, and I wanted to give the WildFly community some context about those changes and how they affect WildFly. The Red Hat announcement can be found on the Red Hat blog: Some key points there are: * Red Hat's Middleware and Integration Engineering and Products teams are moving to IBM in May 2025. * Red Hat will continue to sell and support its Middleware and Integration offerings as they do today; this will not be impacted. * All transitioning Red Hat technology will remain open source and continue to follow an upstream-first development model. Red Hat has sponsored the WildFly project (fka JBoss AS) since 2006, when it bought JBoss, Inc. Now, Red Hat's participation in and support for WildFly is being transferred to IBM. WildFly has a vibrant, healthy community with different kinds of contributions from people from various companies all over the world. Still, it's undoubtedly the case that the bulk of our code contributions come from Red Hat employees working on the middleware product teams that are moving to IBM. However, I don't expect this change to have a significant impact on the WildFly project, beyond the inevitable temporary disruption as the people who are moving focus some of their energy on the move. WildFly is the upstream project for Red Hat's JBoss Enterprise Application Platform (EAP) product. EAP will continue to be sold and supported through Red Hat, and will continue to be developed following an upstream-first development model. That model means that features and fixes for EAP will land first in WildFly's main branch or in the main branches of the components integrated into WildFly. IBM and Red Hat leaders have clearly stated that current and future contributions to WildFly are a key component of their middleware strategy. So, we'll continue to work on behalf of the WildFly community, striving to improve WildFly. Some things we'll be doing: * We'll have another soon. Watch this space for more details! * We're hard at work on WildFly 36, with its final release expected around April 10. * After that, we move on to WildFly 37, which is expected in July. We intend to continue producing feature releases quarterly, followed by a bug fix release about a month later. * Work continues on EE 11 support in WildFly Preview and eventually in standard WildFly. * We'll continue to innovate outside of the Jakarta and MicroProfile areas, including and . * We'll continue to keep up with advancements in Java SE, with an aspiration of having each WildFly feature release run well on the latest SE release available when it comes out, and being able to recommend the latest LTS SE release as the preferred option as soon as possible after it comes out. Last month, I posted about . I intend to continue with this process. Note that our interest in moving to an open source foundation was not triggered by Red Hat's strategy change. We'd been thinking about a move to a foundation since well before we learned about the move to IBM. Personally, I'll be sorry to leave Red Hat, which has been a fantastic place to work. Back in 2006, I was sorry to leave JBoss, Inc for the much bigger Red Hat, too, but it worked out very well. I think combining forces with Java teams at IBM makes a lot of sense and will be good for the middleware projects and products. There's a lot of growth and innovation potential in the middleware technologies we offer and I'm looking forward to being part of a larger team excited about and focused on that potential. Best regards, Brian Stansberry WildFly Project Lead

05 Mar 2025 12:00am GMT

We released Quarkus 3.19.2, the first (we skipped 3.19.0) maintenance release for our 3.19 release train. If you have bugs lurking around, please report them as we aim at stabilizing everything before the next LTS. UPDATE To update to Quarkus 3.19, we recommend updating to the latest version of the Quarkus CLI and run: quarkus update Note that quarkus update can update your applications from any version of Quarkus (including 2.x) to Quarkus 3.19. For more information about the adjustments you need to make to your applications, please refer to the . FULL CHANGELOG You can get the full changelog of on GitHub. COME JOIN US We value your feedback a lot so please report bugs, ask for improvements… Let's build something great together! If you are a Quarkus user or just curious, don't be shy and join our welcoming community: * provide feedback on ; * craft some code and ; * discuss with us on and on the ; * ask your questions on .

05 Mar 2025 12:00am GMT

Join the event on March 11th to , and subscribe to the Meetup to get invitations for future events. Read on to find out about previous topics that have been recorded and upcoming events. -------------------------------------------------------------------------------- It happened to me several times that I was sitting in a workshop about any topic and the term "Keycloak" was used. Not in a spectacular tone, but rather like "We have Keycloak for this and that, and it just works!" Christoph Kofler, COO at Gepardec, had similar experiences. Thus, we already discussed some years ago that Keycloak is somehow an unsung hero, a hidden star, very much appreciated, but not in the spotlight of any encountering or events. End of 2023, we concluded that we want to establish a local community in Austria, very informal, very technical - just for like-minded people to meet, give and take experiences and have a good time together. It was easy to set up the group in the meetup platform () and also announced the in March 2024 at the Red Hat Office in Vienna. To our positive surprise, we almost immediately jumped to 100 members and had 40+ participants on-site. The meeting was framed by a very nice greeting note from the Keycloak founder . We had two great sessions about and from the community and afterward beer and original Leberkäse from . The feedback was overwhelmingly positive, participants talked, laughed and connected till 9 pm. This has motivated us to have two more gatherings in 2024, one at Posedio and one at ÖBB ("Austrian Railway systems") who kindly offered to provide location, food and beverages. Again, the talks lead to lots of questions and discussions which lasted till the late evening. Moreover, we also have established a with all recorded sessions and many members from the local Austrian Keycloak community have participated in in September 2024, organized by . We are looking forward to another which are already planned. If you are interested to participate and/or contribute a talk, please get in touch with us: ,

05 Mar 2025 12:00am GMT

To download the release go to . HIGHLIGHTS SEND RESET EMAIL FORCE LOGIN AGAIN FOR FEDERATED USERS AFTER RESET CREDENTIALS In a new configuration option was added to the reset-credential-email (Send Reset Email) authenticator to allow changing the default behavior after the reset credentials flow. Now the option force-login (Force login after reset) is adding a third configuration value only-federated, which means that the force login is true for federated users and false for the internal database users. The new behavior is now the default. This way all users managed by user federation providers, whose implementation can be not so tightly integrated with Keycloak, are forced to login again after the reset credentials flow to avoid any issue. This change in behavior is due to the secure by default policy. For more information, see . UPGRADING Before upgrading refer to for a complete list of changes. ALL RESOLVED ISSUES BUGS * Invalid migration export for empty database core * Redirect after linking account account/ui * Viewing user events requires `view-realm`-role admin/ui * Keycloak user attribute key broken in Keycloak 26.1.0 admin/ui * When linking IDP to an organization hide on login sets as off admin/ui * SAML2 Client Signing Keys Config does not accept PEM import admin/ui * Comboxes do not display selected option after reset admin/ui * MeterFilter is configured after a Meter has been registered dist/quarkus * CVE-2025-0736 Error during JGroups channel creation may reveal secure information * Admin console: unable to edit user profile attribute either on the form or the JSON editor. admin/ui * CI fails with "Problem creating zip: Execution exception: Java heap space" ci * Error on import of a public key (pem) authentication * Customized quarkus.properties for MySQL cause "Unable to find the JDBC driver (org.h2.Driver)"，The server fails to start. storage * Wrong organization claim assignment in JWT access token organizations * Change default value for force-login option in reset-credential-email authentication * Login form can be used to determine which email addresses / usernames are in the system login/ui * Problems changing pre-defined user profile attributes admin/ui * Upgrade to latest JGroups patch version * CVE-2024-47072 - XStream is vulnerable to a Denial of Service attack due to stack overflow from a manipulated binary input stream * Password policies like NoUsername consider case-sensitivity authentication * External Link Test failing docs * Property Name Casing Mismatch in ProtocolMapperUtils saml

28 Feb 2025 12:00am GMT

Today, we released CVE fixes releases for Quarkus 3.8 LTS and 3.15 LTS to address several CVEs. If you are using these versions and the mentioned components, the update is recommended. These CVEs are already fixed in Quarkus 3.19.1, so if you are using a non-LTS version, please upgrade to Quarkus 3.19.1 (or to the closest LTS version if you are using an old version). We addressed the following CVEs: * - Upstream Netty (only for 3.15) * - Quarkus REST - Using field injection for request-scoped elements in REST resources not marked with the request scope could lead to concurrency issues. * (embargo will be lifted soon) - WebAuthn - The callback endpoint was enabled by default. It now requires to be . * (not published yet) - RESTEasy Classic - RESTEasy Classic endpoints may be affected by memory leaks. If you are exposing REST endpoints publicly using the quarkus-resteasy extension, the update is highly recommended. Quarkus REST is NOT affected by this CVE. COME JOIN US We value your feedback a lot so please report bugs, ask for improvements… Let's build something great together! If you are a Quarkus user or just curious, don't be shy and join our welcoming community: * provide feedback on ; * craft some code and ; * discuss with us on and on the ; * ask your questions on .

27 Feb 2025 12:00am GMT

Today, we released Quarkus 3.19. Quarkus 3.19 is our first step towards the release of our new 3.20 LTS, as 3.20 LTS will be based on the 3.19 branch. You can consider that the next LTS is feature complete and we encourage you to adopt 3.19 and share your feedback. It comes with a lot of enhancements and the following new features: * - Migrate core extensions to @ConfigMapping * - Switch to UBI 9 by default * - Micrometer to OpenTelemetry bridge * - Introduce support for JEP 483's new AOT cache * - WebSockets Next: Allow to send authorization headers from web browsers using JavaScript clients * - WebSockets Next: Support permission checkers * - Support for OAuth2 Demonstrating Proof of Possession UPDATE To update to Quarkus 3.19, we recommend updating to the latest version of the Quarkus CLI and run: quarkus update Note that quarkus update can update your applications from any version of Quarkus (including 2.x) to Quarkus 3.19. For more information about the adjustments you need to make to your applications, please refer to the . WHAT'S NEW? MIGRATION TO @CONFIGMAPPING In 2022, we introduced in Quarkus a new configuration infrastructure for extensions based on interfaces annotated with @ConfigMapping. They were a replacement for the legacy config classes that were used in Quarkus extensions, which came with several issues and were specific to extensions (you couldn't use them in applications). The new @ConfigMapping infrastructure unifies extension and application configuration on the same infrastructure. In Quarkus 3.19, we moved all the core extensions to this new infrastructure (except for some classes that were kept for compatibility purposes). This change might impact you if you were consuming the config classes and, if so, we recommend having a look at the . If you are an extension developer, we encourage you to move to this new infrastructure as, at some point in the future, we will sunset the legacy ones (we will announce a sunsetting plan soon, it will offer you ample time to upgrade). UBI 9 AS DEFAULT We updated the default images across Quarkus to UBI 9 (both to build your applications and run your applications). The will give you ample information on the impact and what you might need to tweak. MICROMETER TO OPENTELEMETRY BRIDGE You can now push your Micrometer metrics to OpenTelemetry using a bridge. Learn more about it in the . JEP 483'S AOT CACHE We have support for AppCDS in Quarkus for quite a while and Quarkus 3.19 generalizes it to also support the AOT cache introduced in JEP 483. It can further improve the startup time, if you generate an AOT cache. WEBSOCKETS NEXT Two new features for WebSockets Next: * The ability to send Authorization headers from web browsers using JavaScript clients - see the . * The support for permission checkers, which were already available for your REST endpoints - see the . SECURITY Our OIDC extension now supports for OAuth 2 tokens. You can find more information about it in our . PLATFORM COMPONENT UPGRADES QUARKUS CXF Quarkus CXF 3.19 was released and is now available in . Check the release notes for more information about what is new in this release. CAMEL QUARKUS Camel Quarkus has been upgraded to 3.19.0. You can consult the for more information. FULL CHANGELOG You can get the full changelog of , , and on GitHub. CONTRIBUTORS The Quarkus community is growing and has now . Many many thanks to each and everyone of them. In particular for the 3.19 release, thanks to Akulov S V, Ales Justin, Alex Martel, Alex Rovner, Alexey Loubyansky, Andrea Boriero, André Pantaleão, Andy Damevin, Bruno Baptista, Chris Laprun, Clement Escoffier, cmoulliard, Damien Clément d'Huart, David Me, Davide D'Alto, dc1248, Eric Deandrea, Erik Mattheis, Felix König, Foivos Zakkak, franz1981, George Gastaldi, Georgios Andrianakis, Gerhard Flothow, Guillaume Smet, Hannah Arndt, Harald Albers, HerrDerb, Holly Cummins, Ivan Béthus, Ivan Petkov, Jakub Gardo, Jakub Jedlicka, Jan Martiska, Jorge Pinto, Julien Ponge, Katia Aresti, Ladislav Thon, Lars Andringa, Loïc Mathieu, Luis Rubiera, Marc Nuri, Marco Bungart, Marco Sappé Griot, Marek Skacelik, mariofusco, marko-bekhta, Martin Kouba, Martin Panzer, Matej Novotny, Matheus Cruz, Matthias Schorsch, Max Rydahl Andersen, Maximilian Zellhofer, melloware, Michael Edgar, Michal Maléř, Michal Vavřík, Ozan Gunalp, pedro_Simoes, Peter Palaga, Phillip Krüger, Roberto Cortez, Rolfe Dlugy-Hegwer, Romain QUINIO, Rostislav Svoboda, Ryan Dens, Sanne Grinovero, Sergey Beryozkin, Severin Gehwolf, Stephan Strate, Stuart Douglas, Stéphane Épardaud, Tobias Haindl, Vincent Potucek, xstefank, and Yoann Rodière. COME JOIN US We value your feedback a lot so please report bugs, ask for improvements… Let's build something great together! If you are a Quarkus user or just curious, don't be shy and join our welcoming community: * provide feedback on ; * craft some code and ; * discuss with us on and on the ; * ask your questions on .

26 Feb 2025 12:00am GMT

is a free event for software developers to meet, share ideas and collaborate. Every year, thousands of developers of free and open source software from all over the world gather at the event. Several talks regarding OpenID Connect and Keycloak have been recorded, and are now available online to re-watch. for the links to the videos. MEETING THE KEYCLOAK COMMUNITY ON-SITE As an incubating project of the Cloud Native Computing Foundation (CNCF), we were happy to share the space of their stand. During the two days, we met with hundreds of existing Keycloak users on-site, as well as with people new to the IAM and identity space. It was fun and exciting to learn what people are doing. We would love to hear more from you about your success stories, what is crucial to your deployments and what can be done better. Fill out the , so we can better understand your use cases, and if you want to share your experience with the wider Keycloak community. VIDEOS TO RE-WATCH These four talks mentioned Keycloak in their talk and on their slides, or are related to OpenID Connect. Did we miss a talk that would be interesting to users of Keycloak? Let us know! Speakers: Takashi Norimatsu, Alexander Schwartz Track: Security Abstract: OAuth 2.0 uses access tokens to grant access to secured resources. When using Single Page Applications, they are passed from browsers to the servers as bearer tokens using HTTP headers. While they are secured in transit using TLS, those tokens could be stolen from a browser, replayed, or mis-used by a malicious or vulnerable server. OAuth 2.0 Demonstrating Proof-of-Possession (DPoP) takes this one step further by equipping the client like your Single Page Application with a key pair so that it can show a proof when passing the access token, so no-one else can use the access token. DPoP is part of the FAPI 2.0 Security Profile by the OpenID Foundation. It promotes best practices on how to protect APIs exposing high-value and sensitive (personal and other) data, for example, in finance, e-health and e-government applications. This talk will explain the concepts and demos how this can be implemented using Keycloak and other open source components. We will also describe the current challenges, limitations and alternatives of the approach. Speaker: Milan Jakobi Track: Identity and Access Management Abstract: Modern web applications strongly rely on Authentication/Authorization infrastructures. To address these needs, the OSS community has strongly endorsed open protocols such as OpenIdConnect and OAuth2, on top of JSON and REST. In turn, these protocols have been implemented in software products such as Keycloak, WSO2 or Lemonldap. OpenId Connect and OAuth2 are authorization protocols, closely aligned with authentication, as provided by Identity Providers. They have been designed within various standardization bodies such as the OpenId foundation or the Internet Engineering Task Force. Understanding these standards is demanding, but needed in order to implement feature-rich solutions, to understand the various options offered to implementers. This talk will therefore discuss in details OIDC and OAuth : the various flows that exist in order to obtain access tokens for standard clients, and some advanced features enabled by these protocols. Track: Identity and Access Management Identity Providers (IdP) based on OAuth 2.0/OIDC and other REST APIs like e.g. Keycloak or Entry ID play a dominant role in the identity management of web-based applications. But organizations which are using IdPs for their internal applications still have to use other services, typically LDAP based, to manage access and authentication to LINUX/POSIX user workstations. To help to avoid running two services for identity management SSSD started to use IdPs to lookup users and authenticate them against the IdPs. In contrast to LDAP there are no standards and conventions with respect to POSIX users and groups in the IdP world. This talk will focus on how SSSD is getting user and group information from IdPs, how information required by POSIX, e.g. the numeric user and group IDs, is created and what kind of limitations there are. Additionally it will be explained why the OAuth 2.0 Device Authorization Flow was chosen for authentication and demonstrated. Speaker: Alexander Schwartz Track: Identity and Access Management Abstract: Authenticating users can start simple with a username and a password for each user. But you will also need to handle forgotten passwords and user registration. You might also want to validate email addresses, add second factors, have users update their profile information as needed, or even offer password-less authentication. A single-sign-on system like Keycloak can handle all that for you and will redirect users after they are authenticated to your applications using the industry standards like OpenID Connect and SAML. Join this talk to see how you can delegate all the tasks around authentication to Keycloak. We will start simple and enable more and more features in our demo to show the functionality and flexibility of Keycloak. We will also look at features of the latest release and the road map ahead. FOSDEM IS ALL ABOUT DEVROOMS! FOSDEM is a big event divided into smaller, single-track conferences with their own call for papers and organizers. Here a short list of those dev rooms that might be of interest for you if you are into Keycloak: Identity and Access Management Devroom is related to operating systems' identity and access management in the free software and open source world. The Security Devroom covers everything that is relevant to security in the free software and open source world. Talks cover topics like cryptography, supply chain, secure development and hardening. The Digital Wallets and Verifiable Credentials DevRoom is about digital wallets, verifiable credentials and the ecosystems emerging from these subjects, especially in the EU.

25 Feb 2025 12:00am GMT

HIGHLIGHTS Today marks a significant milestone in the evolution of Keycloak JS with the release of version 26.2.0. This new version represents a shift in how the JavaScript adapter develops and evolves alongside the Keycloak ecosystem. Although this new version introduces no functional changes to the adapter, it does include several organizational changes. The most notable change is that Keycloak JS now breaks free from the main Keycloak project's release cycle. As , the JavaScript adapter will follow its own independent development path. The separation from the main project allows for more frequent releases of features, bug fixes, and improved responsiveness to community feedback. The JavaScript adapter will continue to be backwards compatible with all actively supported releases of the Keycloak server, and deviation from this will be considered a breaking change. The choice to use a higher version than the main project itself was made intentionally in order to signal to users the departure from Keycloak's release cycle. We will however continue to commit to using , only bumping major versions if backwards incompatible changes are made, as is customary in the . Maintenance updates will continue to land in the 26.1.x series, as it is tied to the current stable release of the Keycloak server, but we encourage users to upgrade to new versions as needed. Another significant change is the relocation of the codebase to its . This structural adjustment is not just administrative-it represents a strategic move toward better maintainability. By separating the JavaScript adapter from the main Keycloak repository, the development team gains greater flexibility in managing the codebase and processing community contributions. If you are looking to provide contributions, or are reporting issues, please redirect your efforts here. Looking ahead, we will be focussing on what is next for Keycloak JS. When it was originally released, only a few OpenID Connect adapters existed for client-side JavaScript, so we needed to make our own adapter. However, this landscape looks very different now, and there are many mature solutions available. The code for Keycloak JS requires modernization and has become challenging to maintain due to the growing complexity. We will continue to evaluate if it makes sense to keep refactoring Keycloak JS, incorporate some mature third-party libraries we can collaborate on, or even replace it with a well-established community solution. UPGRADING Before upgrading refer to for a complete list of changes.

20 Feb 2025 12:00am GMT

The of this blog post series briefly introduced agentic AI and discussed workflow patterns. This post will explore another kind of pattern: agents. The main difference between the two is that workflow patterns are defined programmatically, while agents are more flexible and can handle a broader range of tasks. With agents, the LLM orchestrates the sequence of steps instead of being externally orchestrated programmatically, thus reaching a higher level of autonomy and flexibility. AGENTS Agents differ from the workflow patterns because the control flow is entirely delegated to LLMs instead of being implemented programmatically. To successfully implement agents, the LLM must be able to reason and have access to a set of tools (toolbox). The LLM orchestrates the sequence of steps and decides which tools to call with which parameters. From an external point of view, invoking an agent can be seen as invoking a function that opportunistically invokes tools to complete determinate subtasks. The agent's toolbox can be composed of: * External services (like HTTP endpoints) * Other LLM / agents * Methods providing data from a data store * Methods provided by the application code itself Figure 1. Agents can invoke tools In Quarkus, agents are represented by interfaces annotated with @RegisterAiService. They are called AI services. In that aspect, they are not different from the workflow patterns. The main difference is that the methods of an agent interface are annotated with @ToolBox to declare the tools that the LLM can use to complete the task: @RegisterAiService(modelName = "my-model") // (Booking) b) .mapToInt(b -> b.partySize) .sum(); return sum + partySize

20 Feb 2025 12:00am GMT

19 Feb 2025 6:11pm GMT

If you're part of the Quarkus community, you already know it's fast, lightweight, and designed for cloud-native workloads. But have you ever wondered how other organizations are using Quarkus in production? A new IDC whitepaper, The Quarkus Edge: How Real Customers Achieve Speed, Performance, and Agility, showcases how three organizations have transformed their developer productivity, infrastructure efficiency, and business agility with Quarkus. These case studies highlight why organizations are choosing Quarkus and how it's driving measurable results in industries like telecommunications, transportation, and banking. If you're looking for compelling, real-world stories to share with your peers, leadership, or decision-makers, this report is exactly what you need. Let's dive into the highlights. WHY ORGANIZATIONS ARE CHOOSING QUARKUS The report highlights several common drivers behind Quarkus adoption: ✅ Massive Performance Gains: up to 10x CPU cost reduction and 85% faster start-up times. ✅ Cloud-Native & Kubernetes-Ready: built for containerization and event-driven architectures. ✅ Developer Productivity Boosts: live coding, lower memory footprint, and seamless integration w/ DevOps workflows. ✅ Lower Costs: significant reduction in cloud infrastructure spend, especially for high-throughput, low-latency applications. CASE STUDY #1 (TELCO): POWERING EDGE & IOT WITH QUARKUS A major telecommunications company needed to meet 5G and edge computing demands. After benchmarking against alternatives like Spring WebFlux and Vert.x, they selected Quarkus for its CPU efficiency and latency performance. 🔹 10x reduction in CPU costs, crucial for high-throughput workloads. 🔹 Lower latency, enabling real-time IoT and edge applications. 🔹 Seamless integration with Kafka, RabbitMQ, and event-driven architectures. CASE STUDY #2 (TRANSPORTATION): FASTER EVENT-DRIVEN SERVICES A global transportation services provider turned to Quarkus for its event-driven architecture (EDA). The result was a dramatic reduction in infrastructure footprint and start-up times, helping them move toward a cloud-native future. 🔹 Start-up time reduced from 5-10 minutes to seconds. 🔹 Significantly lower memory and CPU usage, cutting operational costs. 🔹 Seamless event-driven integration with Kafka and reactive messaging. CASE STUDY #3 (BANKING): MODERNIZING FINANCIAL SERVICES A leading European bank began migrating its core banking platform to Quarkus, driven by support discontinuation for legacy systems. They needed a solution that was secure, scalable, and cost-effective. 🔹 85% faster start-up times, improving deployment and system resilience. 🔹 30% more applications hosted on existing infrastructure. 🔹 Increased developer productivity, reducing time-to-market for new financial products. USE THIS REPORT TO ADVOCATE FOR QUARKUS If you're already using or evaluating Quarkus, this report is a powerful tool to help spread the word within your organization. 🔹 developers: share it with your peers to highlight how Quarkus improves developer experience and reduces friction in cloud-native development. 🔹 architects & decision-makers: use the case studies to showcase Quarkus' proven success in real-world deployments. 🔹 executives: the whitepaper quantifies cost savings, performance gains, and business agility, making the case for standardizing on Quarkus. WANT TO SHARE YOUR STORY Tell us how you are using Quarkus by writing your own user story on Quarkus.io.

19 Feb 2025 12:00am GMT

We released Quarkus 3.18.4, the third (we skipped 3.18.0) maintenance release for our 3.18 release train. We will release Quarkus 3.19 next week. UPDATE To update to Quarkus 3.18, we recommend updating to the latest version of the Quarkus CLI and run: quarkus update Note that quarkus update can update your applications from any version of Quarkus (including 2.x) to Quarkus 3.18. For more information about the adjustments you need to make to your applications, please refer to the . FULL CHANGELOG You can get the full changelog of on GitHub. COME JOIN US We value your feedback a lot so please report bugs, ask for improvements… Let's build something great together! If you are a Quarkus user or just curious, don't be shy and join our welcoming community: * provide feedback on ; * craft some code and ; * discuss with us on and on the ; * ask your questions on .

19 Feb 2025 12:00am GMT

The Keycloak homepage has an updated community extensions page! Thanks to , each extension shows off with its GitHub stars. This should provide you with a better overview which extensions are popular with the community. If an extension you use is listed there, give a star! Are you missing an extension? to let us know so we can add it. Click on image below to get the extensions page, or navigate via the and choose "Extensions" there. PS: Did you already give Keycloak a star?

19 Feb 2025 12:00am GMT