fidzu : JBoss

To download the release go to . UPGRADING Before upgrading refer to for a complete list of changes. ALL RESOLVED ISSUES ENHANCEMENTS * Clarify when to use podman docs BUGS * Double click on social provider link causes page has expired error login/ui * IPv6 support: Broker tests failing with proxy configuration ci * After migrating to newer Keycloak, token refreshes using inherited offline sessions return access tokens with invalid exp value oidc * Keycloak 26.2.0 UI Performance Degradation admin/ui * duplicate key value violates unique constraint "constraint_offl_cl_ses_pk3" infinispan * JGroups errors when running a containerized Keycloak in Strict FIPS mode and with Istio infinispan * Update Job Pod is listed in the keycloak discovery service operator

08 May 2025 12:00am GMT

We released Quarkus 3.22.2, the first (we skipped 3.22.0) maintenance release for our 3.22 release train. UPDATE To update to Quarkus 3.22, 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.22. 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 .

07 May 2025 12:00am GMT

07 May 2025 12:00am GMT

To download the release go to . UPGRADING Before upgrading refer to for a complete list of changes. ALL RESOLVED ISSUES NEW FEATURES * Possibility to log details and representation to the jboss-logging listener ENHANCEMENTS * Standardize introductory text in Keycloak guides BUGS * Temporary failure in name resolution with nip.io ci * Unknown error on authentication-flow delete action admin/ui * SAML client certificate not persisted admin/ui * [Keycloak Operator CI] - Test remote (slow) - UpdateTest.testExplicitStrategy ci * Ldap federation seems to open and keep open a new thread/connection for each ldap request ldap * Duplicate Key Violation When Reauthenticating After Account Deletion via Google identity-brokering * Password Policy Changes get overwritten in the UI admin/ui * Kerberos principal attribute value "comes back" when cleared. admin/ui * Client Credentials tab : "Allow regex pattern comparison" toggle is always "On" on page load admin/ui * Filtering of user- and admin-events by dateTo always returns empty results admin/api * Home button always redirects to master realm when permission denied admin/ui * UI: Readonly/disabled profile form input fields are visually indistinguishable from active fields account/ui * [26.2.0/26.1.5] Regression: ClientList value is empty in UI for Custom UserStorageProviderFactory admin/ui * Authentication request can fail with `unknown_error` authentication * Fine-grained-permssion v2 Display problem admin/fine-grained-permissions * UserInfo request fails by using an access token obtained in Hybrid flow with offline_access scope oidc * Keycloak 26.2.0 can't authenticate to the H2 database after the upgrade core * After import of keys an export doesn't include these values admin/ui * Issue with SSL and `CertificatereloadManager` in Keycloak 26.2 when using Istio infinispan * Redirects to admin endpoint 404s on hostname-admin / request scheme mismatch core * [Operator CI] - Test remote (slow) ci * Groups view: Filter/search bar disappears and groups not shown after clearing empty search results admin/ui * Oracle driver problems in keycloak 26.2.1 dependencies * Account console: defaultLocale item in select locale field account/ui * Wrong UDP jgroups metric name docs * Serverinfo response grows over time admin/api * Deletion of a role is slow when when there are a lot of roles in the database core * Duplicate user entries when searching custom attributes core * Aurora DB should not update automatically to the latest minor version ci * Inconsistent "grant_types" vs "grantTypes" Naming Causes GrantTypeCondition to Always Fail core * SLO measurement should mention a month as a period docs

05 May 2025 12:00am GMT

(WASM) has emerged as a powerful technology for running high-performance code in various environments. In this article, we'll explore how to expose WASM binaries as (MCP) tools in WildFly. With 0.5.0 we have introduced a new subsystem to expose WASM (WASI) binaries via CDI, and since we also support MCP tools declaration via CDI, just exposing those binaries as MCP tools was a small step forward. WHAT ARE MCP TOOLS? The Model Context Protocol (MCP) defines a standard way for systems (like an IDE or a CLI) to interact with MCP servers. These servers expose tools (functions that can be executed remotely with specific inputs) and resources (data sources that can be accessed). This allows the client system to leverage the server's capabilities and data for various tasks. BENEFITS OF WASM-BASED MCP TOOLS * Near-native performance for compute-intensive operations * Ability to reuse existing tools written in languages like C, C++, or Rust * Secure execution within WildFly's sandbox environment * Cross-platform compatibility without recompilation DEFINING WASM BINARIES FOR MCP TOOL INTEGRATION Before a WASM module can be exposed as an MCP tool, it needs to be defined within WildFly's WASM subsystem. This subsystem acts as a registry for your WASM modules. It is based on the , an experimental Java SDK using the runtime. CONFIGURATION METHODS You can configure these binaries using either the WildFly CLI or by directly editing the XML configuration (standalone.xml). USING CLI Add a WASM module definition via the CLI like this: /subsystem=wasm/wasm-tool=my-wasm-tool:add(path="/path/to/your/binary.wasm") * my-wasm-tool: A unique name for this binary definition. * path: The location of the .wasm file. This path can be absolute (as in the example above) or relative to the additional relative-to attribute. USING XML CONFIGURATION Alternatively, add the definition within the element in your configuration file: NEXT STEP: CDI INTEGRATION Once defined in the WASM subsystem, these binaries can be injected using CDI. The first way you can use them is to get them by name as an org.wildfly.wasm.api.WasmInvoker using the @WasmTool annotation. This very basic interface wraps the call to the binary, passing the parameters as a byte array and getting the result as a byte array. @Inject @WasmTool(value = "my-wasm-tool") org.wildfly.wasm.api.WasmInvoker greet; public String greet(String person) { // "greet" is the name of the exported method of the WASM module byte[] output = greet.call("greet", person.getBytes(StandardCharsets.UTF_8)); return new String(output, StandardCharsets.UTF_8); } A second way is to use the @WasmToolService over an interface to create a dynamic proxy wrapping the call to the WASM module and providing a way to serialize and deserialize your arguments to the byte array required by the invoker. @WasmToolService(wasmToolConfigurationName = "pizza", wasmMethodName = "retrievePizzeriaAddresses", argumentSerializer = CityJsonSerializer.class) public interface Pizza { public String pizzas(String city); } Here you can see that we are calling the exported method retrievePizzeriaAddresses on the WASM module registered with the name pizza in WildFly configuration and the `CityJsonSerializer`class is in charge with converting the java.lang.String city to a JSON object to be consumed by the WASM module. Once defined in the WASM subsystem, these binaries can be injected using CDI and subsequently exposed as MCP tools, which we'll cover in the next step. NEXT STEP: MCP INTEGRATION Well this is the simplest part as we 'just' have to use our MCP annotations and WildFly Glow will provision the MCP server for us. Note also that WildFly MCP server support is SSE only (no stdio). Our WASM service now becomes: import org.wildfly.mcp.api.Tool; import org.wildfly.mcp.api.ToolArg; import org.wildfly.wasm.api.WasmToolService; @WasmToolService(wasmToolConfigurationName = "pizza", wasmMethodName = "retrievePizzeriaAddresses", argumentSerializer = CityJsonSerializer.class) public interface Pizza { @Tool(name="pizzaRetriever", description = "Get the address for the best hawaian pizzas") public String pizzas(@ToolArg(description = "The city where we are looking for Hawaian pizza") String city); } And now there is a new pizzaRetriever MCP tool available :) The source for this example is . Deploying Wasm binaries in WildFly and exposing them as MCP tools

05 May 2025 12:00am GMT

Byteman 4.0.25 is now available from the and from the . It is the latest update release for use on all JDK9+ runtimes up to and including JDK25 Byteman 4.0.25 is a maintenance release which enables Byteman to be used with JDK25 releases. More details are provided in the and the latest .

01 May 2025 5:12pm GMT

I'm pleased to announce that WildFly has joined the as a member project. WildFly is a well-established project that wishes to continue to grow and develop. We believe being associated with Commonhaus can help us: * Grow our contributor and user communities by associating the project with a vendor-neutral foundation. * Update our governance model to incorporate current open source best practices. * Continue to improve our openness when it comes to roadmaps, designs and solution discussions. We want to continue to evolve and improve, but we also have a lot of experience running a successful and very complex project. We believe Commonhaus' guiding principles around honoring project and community identity and offering guidance instead of mandates, with its "community-first" governance model, make it an excellent fit for WildFly. For more on the thinking that led to us joining Commonhaus, you can have a look at the about moving to a foundation, watch a of the WildFly Mini Conference session on this last month, or have a look at the . Moving a project to a foundation primarily consists of transferring intellectual property associated with the project (logos, trademarks, domain names, etc., currently owned by WildFly's sponsor, Red Hat) to the foundation, and adapting the project's governance and operations to the requirements of the foundation. We've begun the process of doing that - what Commonhaus calls 'onboarding'. I expect this will take some time to complete. If you're interested in following this process, keep an eye on the , where I'm sure there will be many threads about this move. I don't expect most of the details of onboarding to be particularly impactful to end users of WildFly, or even to most WildFly developers. But definitely something that will be impactful will be updating WildFly's formal governance model from one based on sponsorship by Red Hat to one appropriate for a project in a vendor-neutral foundation. I expect over the coming weeks we'll have a number of discussions on the wildfly-dev list about what an updated governance model should look like. I'm really looking forward to those discussions and I encourage everyone in the WildFly community to participate. COMMUNITY FEEDBACK We'd love to hear your thoughts on this. Let us know what you're thinking either on the , in the or in . Best regards, Brian

30 Apr 2025 12:00am GMT

WHAT'S CHANGING? The internals of Quarkus test classloading have been rewritten in 3.22. It does not affect production and dev modes, or some Quarkus test modes, such as @QuarkusIntegrationTest, @QuarkusComponentTest. However, @QuarkusTest has changed. This change should make Quarkus testing work better, and it allowed us to fix a pile of longstanding bugs. It will also allow us to improve the integration with test frameworks such as Pact. However, it did introduce a few bugs we know about, and most likely also some bugs we don't yet know about. We're keen to get feedback from the community so that we can get fixing. WHY? In previous versions, Quarkus tests were invoked using the default JUnit classloader, and then executed in a different, Quarkus-aware, classloader. This mostly worked very well, and meant that QuarkusTest tests mostly behaved as if they were part of the same application as the code under test. The Quarkus test framework could start and stop Quarkus instances at the right point in the test lifecycle, inject CDI dependencies, and do other useful Quarkus bytecode manipulation. However, some use cases didn't work. Tests using advanced JUnit 5 features like @TestTemplate and @ParameterizedTest sometimes found that the same test code might appear to run in several classloaders in a single test, or that injected dependencies weren't always available. While Quarkus extensions can do all sorts of marvellous bytecode manipulation to improve the developer experience, they cannot manipulate test classes with the same freedom that they do normal application classes. Over time, test-related defects were building up that couldn't be changed without a fundamental rewrite of how Quarkus loads and executes tests. The Quarkus test code itself was also growing ever-more complex as it tried to work around various JUnit edge cases. Moving test instances from one classloader to another involved serializing and deserialization, which is harder to implement on newer JVM versions with tighter class security. For example, Quarkus used to use XStream as the serialization provider, but XStream no longer works with Java 17 and higher, because of reflection restrictions in the newer JVMs. What if, instead, Quarkus tests were simply run in the same classloader used to to load them? WHAT YOU NEED TO DO From Quarkus 3.22 onwards, this is exactly how @QuarkusTest classloading works. What do your tests need to change in order to work with the new architecture? Nothing (hopefully!). One of the goals of this change was that the rewrite didn't touch any tests in our test suite, to make sure they'd all continue working without updates. In practice, there have been a few hiccups and we've also discovered some edge cases in the broader ecosystem. KNOWN REGRESSIONS * All dev services now start in the JUnit discovery phase. are currently started during , along with bytecode manipulation and other application initialization steps. With the new testing design, all augmentation happens at the beginning of the test run, during the JUnit discovery phase. This means all Dev Services also start at the beginning of the test run. If several test classes with different Dev Service configuration are augmented before any tests are run, multiple differently-configured Dev Services may be running at the same time. This can cause port conflicts and cross-talk on configuration values. We're hoping to have a for this in the next release. As a workaround, splitting conflicting tests into separate projects should fix symptoms. * Config access from JUnit conditions. Using a ConfigProvider from a custom JUnit condition will . The workaround is to set the thread context classloader to this.getClass().getClassLoader() before reading config, and then set it back afterwards. * Nested test issues. If nested @QuarkusTest tests are mixed in the same project with plain tests, the plain tests , because the thread context classloader does not get correctly reset. As a workaround, you can manually set the thread context classloader to the system classloader in the plain tests. The nested tests also . * junit-platform.properties Including a junit-platform.properties in a Gradle project for `@QuarkusTest`s. * Eclipse support. Running QuarkusTest tests from the Eclipse IDE is . Right-clicking and running individual test methods works, and running a whole package also works. But running at the class level gives an error. * Increased memory footprint running tests. For suites using multiple profiles and resources, more heap or metaspace may be needed. THINGS TO WATCH OUT FOR * Test order change. As part of the rewrite, the execution order of some tests has swapped around. Of course, we all know tests should not depend on execution order if they don't set an order explicitly. However, it's easy to not notice that a test requires a certain order… until the order changes. We discovered some tests in our own suite that were sensitive to the execution order, and other people may make similar discoveries. * Test timing change. We also discovered that the rewrite exposed some timing issues in tests. Because classloading is frontloaded at the beginning of the test run, rather than between test executions, there's less time for asynchronous operations to finish between tests. For example, there may no longer be time for external state to 'reset' before the next test starts. This might expose some heisenbugs in test suites. DROPPED SUPPORT * @TestProfile on @Nested tests. Mixing different test profiles and test resources on @Nested tests is no longer supported. By definition, every @TestProfile must get its own Quarkus application and classloader. Having multiple classloaders execute one test isn't compatible with loading the test with the classloader used to run it. * Version 2.x of the Maven Surefire plugin. Versions below 3.x of the Maven Surefire plugin will no longer work with @QuarkusTest. Version 3 of the Surefire plugin was released in 2023, so version 2 is now rather old. NEXT STEPS The main work of the test classloading rewrite has been delivered in 3.22, and has unlocked a bunch of possible improvements. Some test defects weren't directly fixed by the main change, but the architecture is now in place to enable a fix. More excitingly, test-related extensions, like the Pact extensions, can now add new features to reduce test boilerplate. As always, if you spot issues or oddities, please let us know on or . The is still underway, and welcomes contributions.

30 Apr 2025 12:00am GMT

Today, we released Quarkus 3.22. It comes with several important features, together with some infrastructure improvements: * - Compose Dev Services * - Improved testing class loader infrastructure * - Allow Hibernate ORM and Hibernate Reactive to be used in the same application * - Apply validation modes to the Hibernate Reactive session factory config / Add tests for Reactive + Validator * - Dedicated Dev UI interface to execute HQL (Hibernate ORM) queries * - Add Jakarta Data documentation, dependency management and tests * - Allow setting Clear-Site-Data on OIDC logout * - Add OIDC expanded configuration reference * - Support customization of gRPC server building * - Make Stork optional for REST Client UPDATE To update to Quarkus 3.22, 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.22. For more information about the adjustments you need to make to your applications, please refer to the . WHAT'S NEW? COMPOSE DEV SERVICES Dev Services is one of the key developer joy feature of Quarkus. It has been around for quite some time and is very handy to get simple containers started in dev and test modes. Quarkus 3.22 introduces the ability to compose and orchestrate complex container setups as Dev Services, by leveraging the Compose approach offered by Docker and Podman. You can learn all about it in the . IMPROVED TESTING CLASS LOADER INFRASTRUCTURE This one has been in the works for quite some time and we are pleased to announce a new testing class loader infrastructure. It fixes a lot of issues but might also introduce some issues - even if we tried hard to squash all of them. You can learn (a lot!) more about it in . If you encounter any weird class loading issues in your tests, please report back! HIBERNATE ORM AND HIBERNATE REACTIVE We used to not be able to mix Hibernate ORM and Hibernate Reactive in the same application. This limitation has now been lifted and you can leverage the strengths of both extensions in the same app. Also, Hibernate Validator is now properly integrated with Hibernate Reactive. Finally, Quarkus 3.22 includes a new Dev UI feature: you can execute HQL queries (as in Hibernate Query Language) directly in the Dev UI, allowing you to very easily test your HQL queries and iterate on them. JAKARTA DATA Jakarta Data has been supported by Quarkus since its inception but it wasn't properly documented. It has now a in the Hibernate ORM guide. The Jakarta Data dependencies have been added to our BOM. OIDC Starting with 3.22, on OIDC logout, you have the ability to set Clear-Site-Data header by using the quarkus.oidc.logout.clear-site-data configuration property. We also added a with extensive coverage of the OIDC configuration. GRPC It is now possible to customize the gRPC server building by implementing the ServerBuilderCustomizer interface. You can find out more about in the added to the documentation. STORK To avoid having to initialize Stork even if not needed, Stork is no longer a hard dependency of the REST Client. If you want to leverage Stork with the REST Client, you need to add the Stork extension to your build file. PLATFORM COMPONENT UPGRADES QUARKUS CXF Quarkus CXF 3.22 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.22.0. AMAZON SERVICES The Amazon Services extensions have been upgraded to version 3.5.0. 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.22 release, thanks to Aixi-dev, Ales Justin, Alexey Loubyansky, Andreas Eberle, Andy Damevin, Antonio Musarra, Auri Munoz, Barry LaFond, Bruno Baptista, Clemens Classen, Clement Escoffier, Davide D'Alto, Digvijay Singh, elmodeer, Eric Deandrea, Esben Nedergaard, Fabian, Fabian Senn, feibl, Foivos Zakkak, franz1981, George Gastaldi, Georgios Andrianakis, Giancarlo Calderón Cárdenas, Guillaume Smet, Harry Chan, Holly Cummins, holomekc, Inaki Villar, ineednousername, Jan Martiska, Jeremie Bresson, Johnathan Gilday, Juan Antonio Breña Moral, Julien Ponge, Junes, Karm Michal Babacek, Katia Aresti, Ladislav Thon, Loïc Mathieu, Luca Basso Ricci, Luca Molteni, Marco Belladelli, mariofusco, marko-bekhta, Martin Bartoš, Martin Kouba, Martin Panzer, Matej Novotny, Matheus Cruz, Matheus Oliveira da Silva, Maximilian Zellhofer, Michael Edgar, Michael Musgrove, Michal Vavřík, Michiel Dockx, Mikhail Polivakha, Ozan Gunalp, Ozzy, Paulo Casaes, Peter Palaga, Phillip Krüger, Roberto Balarezo, Roberto Cortez, Rod Cheater, Rostislav Svoboda, Rüdiger zu Dohna, Sergey Beryozkin, shjones, Stuart Douglas, Stéphane Épardaud, Tamas Cservenak, Vardhman, w0pp, Yassine Haouzane, Yoann Rodière, and Yoshikazu Nojima. 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 .

30 Apr 2025 12:00am GMT

To download the release go to . UPGRADING Before upgrading refer to for a complete list of changes. ALL RESOLVED ISSUES ENHANCEMENTS * Make distribution startup timeout configurable testsuite BUGS * [Keycloak CI] - FIPS UT - Run crypto tests ci * CVE-2025-3910 Two factor authentication bypass * CVE-2025-3501 Keycloak hostname verification

30 Apr 2025 12:00am GMT

INTRODUCTION introduces an flow. While it will take a bit of time for the new MCP specification to be widely supported, you can already add authentication to client and server following the . You only need an MCP client that can receive an access token and pass it to the MCP server and, obviously, an MCP server that verifies the token. In this post, we will detail how you can enforce authentication with the . We will first use Keycloak as an OpenID Connect (OIDC) provider to login and use a Keycloak JWT access token to access the server with Quarkus MCP SSE Server Dev UI in dev mode. Secondly, we will show how to log in using GitHub OAuth2 and use a GitHub binary access token to access the server in prod mode with both and the curl tools. STEP 1 - CREATE AN MCP SERVER USING THE SSE TRANSPORT First, let's create a secure Quarkus MCP SSE server that requires authentication to establish Server-Sent Events (SSE) connection and also when invoking the tools. You can find the complete project source in the . MAVEN DEPENDENCIES Add the following dependencies: io.quarkiverse.mcp quarkus-mcp-server-sse (1) 1.1.1 io.quarkus quarkus-oidc (2) 1 quarkus-mcp-server-sse is required to support MCP SSE transport. 2 quarkus-oidc is required to secure access to MCP SSE endpoints. Its version is defined in the Quarkus BOM. TOOL Let's create a tool that can be invoked only if the current MCP request is authenticated: package org.acme; import io.quarkiverse.mcp.server.TextContent; import io.quarkiverse.mcp.server.Tool; import io.quarkus.security.Authenticated; import io.quarkus.security.identity.SecurityIdentity; import jakarta.inject.Inject; public class ServerFeatures { @Inject SecurityIdentity identity; @Tool(name = "user-name-provider", description = "Provides a name of the current user") (1) @Authenticated (2) TextContent provideUserName() { return new TextContent(identity.getPrincipal().getName()); (3) } } 1 Provide a tool that can return a name of the current user. Note the user-name-provider tool name, you will use it later for a tool call. 2 Require authenticated tool access - yes, the only difference with an unauthenticated MCP server tool is @Authenticated, that's it! See also how the main MCP SSE endpoint is secured in the section below. 3 Use the injected SecurityIdentity to return the current user's name. CONFIGURATION Finally, let's configure our secure MCP server: quarkus.http.auth.permission.authenticated.paths=/mcp/sse (1) quarkus.http.auth.permission.authenticated.policy=authenticated 1 Enforce an authenticated access to the main MCP SSE endpoint during the initial handshake. See also how the tool is secured with an annotation in the section above, though you can also secure access to the tool by listing both main and tools endpoints in the configuration, for example: quarkus.http.auth.permission.authenticated.paths=/mcp/sse,/mcp/messages/*. We are ready to test our secure MCP server in dev mode. STEP 2 - ACCESS THE MCP SERVER IN DEV MODE START THE MCP SERVER IN DEV MODE mvn quarkus:dev The configuration properties that we set in the section above are sufficient to start the application in dev mode. The OIDC configuration is provided in dev mode automatically by . It creates a default realm, client and adds two users, alice and bob, for you to get started with OIDC immediately. You can also register a custom Keycloak realm to work with the existing realm, client and user registrations. You can also login to other OIDC and OAuth2 providers in OIDC Dev UI, see the section for more details. USE OIDC DEV UI TO LOGIN AND COPY ACCESS TOKEN Go to , find the OpenId Connect card: Follow the Keycloak Provider link and using an alice name and an alice password. You can login to other providers such as Auth0 or from OIDC DevUI as well. The only requirement is to update your application registration to allow callbacks to DevUI. For example, see how you can . After logging in with Keycloak as alice, copy the acquired access token using a provided copy button: USE QUARKUS MCP SERVER DEV UI TO ACCESS THE MCP SERVER Make sure to login and copy the access token as explained in the section above. Go to , find the MCP Server card: Select its Tools option and choose to Call the user-name-provider tool: Paste the copied Keycloak access token into the Tool's Bearer token field, and request a new MCP SSE session: Make a tool call and get a response which contains the alice user name: All is good in dev mode; it is time to see how it will work in prod mode. Before that, stop the MCP server, which runs in dev mode. STEP 3 - ACCESS THE MCP SERVER IN PROD MODE REGISTER GITHUB OAUTH2 APPLICATION Before it was all in dev mode - using Quarkus devservices to try things out. Now, let's move to prod mode. If you already have a Keycloak instance running then you can use it. But to illustrate how OAuth2 works with more than just Keycloak, we will switch to GitHub OAuth2 when the application runs in prod mode. First, start with registering a GitHub OAuth2 application. Follow the process, and make sure to register the callback URL. Next, use the client id and secret generated during the GitHub OAuth2 application registration to . UPDATE THE CONFIGURATION TO SUPPORT GITHUB The that was used to run the MCP server in dev mode was suffient because Keycloak Dev Service was supporting the OIDC login. To work with GitHub in prod mode, we update the configuration as follows: quarkus.http.auth.permission.authenticated.paths=/mcp/sse (1) quarkus.http.auth.permission.authenticated.policy=authenticated %prod.quarkus.oidc.provider=github (2) %prod.quarkus.oidc.application-type=service (3) %prod.quarkus.oidc.login.provider=github (4) %prod.quarkus.oidc.login.client-id=github-application-client-id (5) %prod.quarkus.oidc.login.credentials.secret=github-application-client-secret (5) 1 Enforce an authenticated access to the main MCP SSE endpoint during the initial handshake. See also how the tool is secured with an annotation in the section above. 2 Default Quarkus OIDC configuration requires that only GitHub access tokens can be used to access MCP SSE server. 3 By default, quarkus.oidc.provider=github supports an authorization code flow only. quarkus.oidc.application-type=service overrides it and requires the use of bearer tokens. 4 Use GitHub authorization code flow to support the login endpoint with a dedicated Quarkus OIDC login configuration. 5 Use the client id and secret generated in the section. Note the use of the %prod. prefixes. It ensures the configuration properties prefixed with %prod. are only effective in prod mode and do not interfere with dev mode. IMPLEMENT LOGIN ENDPOINT Currently, MCP clients can not use the authorization code flow themselves. Therefore, we implement an OAuth2 login endpoint that will return a GitHub token for the user to use with MCP clients, which can work with bearer tokens. Add another dependency to support Qute templates: io.quarkus quarkus-rest-qute (1) 1 quarkus-rest-qute is required to generate HTML pages. Its version is defined in the Quarkus BOM. and implement the login endpoint: package org.acme; import io.quarkus.oidc.AccessTokenCredential; import io.quarkus.oidc.UserInfo; import io.quarkus.qute.Template; import io.quarkus.qute.TemplateInstance; import io.quarkus.security.Authenticated; import jakarta.inject.Inject; import jakarta.ws.rs.GET; import jakarta.ws.rs.Path; import jakarta.ws.rs.Produces; @Path("/login") @Authenticated public class LoginResource { @Inject UserInfo userInfo; (1) @Inject AccessTokenCredential accessToken; (2) @Inject Template accessTokenPage; @GET @Produces("text/html") public TemplateInstance poem() { return accessTokenPage .data("name", userInfo.getName()) .data("accessToken", accessToken.getToken()); (3) } } 1 GitHub access tokens are binary and Quarkus OIDC indirectly verifies them by using them to request GitHub specific UserInfo representation. 2 AccessTokenCredential is used to capture a binary GitHub access token. 3 After the user logs in to GitHub and is redirected to this endpoint, the access token will be returned to the user in an HTML page generated with a simple . Of course, you would not do that in a real application. It is just an example to demonstrate the capability. PACKAGE AND RUN THE MCP SERVER Package the MCP server application: mvn package Run it: java -jar target/quarkus-app/quarkus-run.jar You can also run the MCP server from its Maven coordinates directly with jbang: mvn install jbang org.acme:secure-mcp-sse-server:1.0.0-SNAPSHOT:runner LOGIN TO GITHUB AND COPY THE ACCESS TOKEN Access , login to GitHub, and copy the returned access token: By default, Quarkus GitHub provider submits the client id and secret in the HTTP Authorization header. However, GitHub may require that both client id and secret are submitted as form parameters instead. When you get HTTP 401 error after logging in to GitHub and being redirected back to Quarkus MCP server, try to replace %prod.quarkus.oidc.login.credentials.secret=${github.client.secret} property with the following two properties instead: %prod.quarkus.oidc.login.credentials.client-secret.method=post %prod.quarkus.oidc.login.credentials.client-secret.value=${github.client.secret} USE MCP INSPECTOR TO ACCESS THE MCP SERVER is an interactive developer tool for testing and debugging MCP servers. Let's use it to invoke our MCP server with the authentication. Launch : npx @modelcontextprotocol/inspector Ensure that you have version 0.6.0 or later installed as it adds support for specifying bearer token authentication. Navigate to the URL provided into a browser. Change the Transport Type dropdown to SSE and the URL to so that it targets the running Quarkus MCP Server: Select the Authorization button and paste the copied GitHub access token from the browser to the Bearer Token field and connect to the Quarkus MCP SSE server: Next, make a user-name-provider tool call: You will see the name from your GitHub account returned. USE CURL TO ACCESS THE MCP SERVER Finally, let's use curl and also learn a little bit how both the MCP protocol and MCP SSE transport work. First, open a new terminal window and access the main SSE endpoint without the GitHub access token: curl -v localhost:8080/mcp/sse You will get HTTP 401 error. Use the access token that was obtained previously to access MCP server: curl -v -H "Authorization: Bearer gho_..." localhost:8080/mcp/sse and get an SSE response such as:

28 Apr 2025 12:00am GMT

KeyConf24 was a fantastic success, bringing together identity and access management professionals, developers, and community members from across Europe. The day was packed with insightful talks, deep dives into Keycloak, and incredible conversations between some of the brightest minds in IAM. Now, we're excited to take things even further. 📍 Introducing - taking place in Amsterdam on August 28th, 2025! This year's edition of the Keycloak Identity Summit promises more content, more connections, and even more opportunities to engage with the people shaping the future of identity and access management. WHAT TO EXPECT AT KEYCONF25 Inspiring Keynote Speakers Hear directly from thought leaders, core contributors, and experts working on the cutting edge of Keycloak and open identity standards. Connect with like-minded professionals From long-time contributors to those just starting their IAM journey, KEYCONF25 is the perfect place to meet others working with identity, OAuth2, OIDC, and more. Networking lunch Our extended lunch break is designed to help you meet fellow attendees, swap ideas, and build meaningful professional connections in a relaxed setting. Business drinks Stick around after the last session for informal networking over drinks. Want to sponsor this year's Business Drink? Get in touch with us-we'd love to partner with you! Expert sessions and real-world use cases Gain practical insights into Keycloak implementation, security improvements, OAuth2 best practices, and evolving identity standards. Topics and speakers to be announced soon! SAVE THE DATE AND JOIN US! Whether you're a developer, architect, security specialist, or product owner, KEYCONF25 is your opportunity to gain knowledge, grow your network, and contribute to the future of the Keycloak community. 📅 August 28th, 2025 📍 Amsterdam, Netherlands Tickets are now available at - secure your spot early! WANT TO GET INVOLVED? We're actively seeking sponsors and speakers for KEYCONF25. If you'd like to share your expertise or support this community-driven event, please get in touch at . Let's continue building a stronger, smarter IAM community-together. We can't wait to see you in Amsterdam!

28 Apr 2025 12:00am GMT

We released Quarkus 3.21.4, the fourth maintenance release for our 3.21 release train. UPDATE To update to Quarkus 3.21, 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.21. 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 .

24 Apr 2025 12:00am GMT

When running a central single sign on service like Keycloak in production, you need to understand how well the system performs and whether there are service degradations. Having a proper monitoring stack in place is essential for this. Moreover, when the system performance degrades, it is crucial to identify which part of the system is causing the problem to address it. In the latest Keycloak release, all the above became more straightforward and works without additional extensions. Read on to learn more and ! HEY KEYCLOAK! HOW ARE YOU? Users rely on Keycloak to log in to their applications, and service level indicators (SLIs) capture the key metrics capturing that behavior. Misbehavior of the system can be detected by monitoring these SLIs. One of the indicators can be the availability of the system. The indicator for availability can be defined as: percentage of the time the system can answer requests. The lower the indicator is for your system, the less available it was in the observed period. Find an example set of SLIs for Keycloak and more details on this topic in the guide. OH NO! YOU ARE NOT DOING WELL? Now we know how to detect when Keycloak is not performing well. But what should I do when a service level indicator shows a degradation of the service? This situation usually means some part of Keycloak does not perform well. However, from the indicator itself, it is hard to say what part of Keycloak it is. To identify the culprit of the problem, we provide the guide that lists chosen metrics. Using these metrics, you can visualize what is happening in your deployment and down problems. Some examples of metrics from the guide are listed below: * Number of operations performed by Keycloak like password hashes, login flows, token refreshes, etc. * Memory usage * Database connection pool utilization * Number of HTTP requests per URL and outcome * Hit ratios for internal caches For environments with Prometheus for collecting metrics and Grafana for displaying them, we also provide Grafana dashboards to make troubleshooting smoother. Find instructions on how to deploy our dashboards into your Grafana instance in the guide. Grafana dashboards with SLIs (click to enlarge) MY KEYCLOAK IS STILL SICK :( I NEED AN IN-DEPTH EXAMINATION Thanks to metrics, you can observe certain aspects of the system and how they evolve over time. However, they may not provide a detailed picture of what is happening inside Keycloak for a specific request. For this, you can leverage traces. Learn more in the guide. With tracing, you can observe steps that Keycloak was performing for a specific request, including the respective timing for each of them. These steps include operations by Keycloak but also waiting time for responses from third party services like the database, LDAP, Infinispan and others. This helps you to reveal where the bottleneck in your system is. In the example below, you can see steps Keycloak was performing when a user submitted the username and password form. You can see the most time-consuming step was password hashing, which took 30 milliseconds out of 48-millisecond total request processing time. Trace displayed in Jaeger (click to enlarge) NEXT STEPS To see all of this in action and to ask live questions, . As an appetizer, see a shorter version of . To ask questions outside the meetup, use the . Use to join the CNCF Slack if you do not have an account yet. You can also leave the feedback in the .

24 Apr 2025 12:00am GMT

To download the release go to . UPGRADING Before upgrading refer to for a complete list of changes. ALL RESOLVED ISSUES ENHANCEMENTS * Clarify upgrade instructions * Change the title for Grafana dashboards guide to plural docs * Document operator `Auto` update strategy when used with `podTemplate` BUGS * [FGAP] [UI] Permission search doesn't execute correct consequent search request admin/fine-grained-permissions * Test coverage for count menthods when filtering admin/fine-grained-permissions * Make group required when selecting a specific group creating a premission admin/ui * Test failures in CI in Chrome tests ci * StatefulSet reconciliation infinitely looping operator * [FGAP] AvailableRoleMappings do not consider all-clients permissions admin/fine-grained-permissions * Downstream docs have duplicate ID on sampling docs * Blocking issue with increasing JVM thread count after migrating from 26.0.8 to 26.1.4 infinispan * Permission details sometimes don't show the name of the client admin/fine-grained-permissions * [Docs] Broken link in ExternalLinksTest for importmap docs * Liquibase checksum mismatch when upgrading from Keycloak ≤ 22.0.4 directly to 26.2.x storage * JpaRealmProvider getGroupByName return group duplicate due to change of comparison (like vs equal) ldap * Keycloak operator with update strategy to Auto: missing imagePullSecrets operator * Release note 26.2.0 has broken link docs

23 Apr 2025 12:00am GMT

23 Apr 2025 12:00am GMT