Published latest aggregated blog posts

Author: jbossorg-bot

src/content/posts-aggregator/1.json

@@ -1,14 +1,13 @@
 {
-  "title": "Register now for KubeCon Japan in June",
-  "link": "https://www.keycloak.org/2025/03/keycloak-kubecon25-japan-announce",
+  "title": "Infinispan 15.2.0.Final",
+  "link": "https://infinispan.org/blog/2025/03/27/infinispan-15-2",
   "author": [
     {
-      "name": "Alexander Schwartz",
-      "avatar": null
+      "name": "Tristan Tarrant",
+      "avatar": "https://www.gravatar.com/avatar/b91126c20f0d38f1ce1750d5a2b2bcb8?s=50"
     }
   ],
   "date": "2025-03-27T00:00:00.000Z",
-  "feed_title": "Keycloak Blog",
-  "feed_avatar": "https://www.gravatar.com/avatar/87fe00619f08c241da8dfb23d907ffa2?s=50",
-  "content": "This year is the first time there is a KubeCon in Japan, and the Keycloak project is excited to be part of it! Join us on June 16-17 2025 in Tokyo, Japan for this exciting event.    Keycloak has a powerful community in Japan, and we have received several contributions in the past. There will be two talks about Keycloak (see below).     TALKS AT KUBECON  The schedule of KubeCon + CloudNativeCon Japan 2025 has been released, see below talks about Keycloak:   *     Monday June 16, 2025 11:30 - 12:00 JST    Takashi Norimatsu, Hitachi & Marek Posolda, Red Hat   *     Tuesday June 17, 2025 14:50 - 15:20 JST    Yoshiyuki Tabata, Hitachi, Ltd.  We’re preparing for KubeCon Japan 2025 and can’t wait to connect with our community. Mark your calendars and join us.  See you in Tokyo!"
+  "feed_title": "Infinispan",
+  "content": "\"Feelin' Blue\"  It’s new. It’s blue. It’s Infinispan 15.2, codenamed .    Without further ado, here’s a list of what’s new (and I promise to stop with the Dr. Seuss rhyming):   RESP ENDPOINT   JSON  Infinispan now implements the .   LUA SCRIPTING  It is now possible to run . The big advantage is that this works in Infinispan clusters, without having to worry about key ownership.   SERVER  All endpoints limit the maximum request size, which defaults to 10MB. This protects your server from abuse. Use the max-content-length configuration attribute to change it to your liking.   METRICS  You can now disable exporting the base (JVM) metrics, which is desirable when running in embedded mode. Such metrics are usually exported by the application framework.   CONSOLE  The console sports a new look & feel, thanks to the upgrade to .    Manage roles, users and access control for Principal Role Mappers from the console.     FIXES  Lots of these. However, should you find something that doesn’t work, head over to our and provide any details that help us debug and solve problems.   JDK REQUIREMENTS  Like the previous 15.x releases, you will need at least JDK 17 in order to use Infinispan 15.2. Infinispan also supports the recently released JDK 24.   DEPRECATIONS AND REMOVALS  We are no longer building the native server, since it did not provide the same level of functionality and performance as our Java server. However, if you miss it, please let us know your use case, and we’ll look into bringing it back.   DOCUMENTATION  Our documentation now includes * * As usual, many improvements, updates and fixes.   RELEASE NOTES  You can look at the to see what was changed since our last development build.  Get them from our ."
 }

src/content/posts-aggregator/10.json

@@ -1,13 +1,13 @@
 {
-  "title": "How Orange leverages Quarkus for seamless access to Telco network capabilities",
-  "link": "https://quarkus.io/blog/orange-telco-core-network-api-management-with-quarkus/",
+  "title": "Sender-constraining access tokens with Quarkus OIDC",
+  "link": "https://quarkus.io/blog/sender-constraining-tokens/",
   "author": [
     {
-      "name": "Thomas Segismont",
+      "name": "Sergey Beryozkin",
       "avatar": null
     }
   ],
-  "date": "2025-03-18T00:00:00.000Z",
+  "date": "2025-03-19T00:00:00.000Z",
   "feed_title": "Quarkus",
-  "content": "INTRODUCTION  As a global telecommunications leader, has always been at the forefront of innovation. Along with Deutsche Telekom, Telefónica, and Vodafone, Orange co-founded the , an initiative aimed at simplifying the consumption of 5G APIs for third-party application developers.  To achieve this goal, Orange needed a flexible and lightweight framework capable of handling constrained API exposure while ensuring compatibility with existing network core systems.  After a rigorous evaluation of multiple frameworks and toolkits — including Quarkus, Ktor, Micronaut, and Vert.x — Orange selected Quarkus as the ideal solution.  , software craftsman at Orange, told us why.   WHY QUARKUS? A FRAMEWORK EVALUATION  The team at Orange identified application startup time as a barrier to dynamic Kubernetes pod management. So they embarked on a comparative study to test alternatives to Spring Boot in a well-defined API wrapper exposure context. Key evaluation criteria included:   * Learning Curve: How easily could a Spring developer transition?   * Kotlin Compatibility: Could the framework work seamlessly with Kotlin?   * Runtime footprint: Could it operate efficiently in a constrained environment?   * Ease of Deployment: How smoothly could it be deployed on Kubernetes?  After extensive testing, Quarkus stood out for multiple reasons:   * Simplicity: A relatively simple learning curve, especially for those familiar    with JAX-RS / Jakarta REST.   * Dev Mode: Very fast startup, live reload and zero configuration Dev Services    (Vault, Redis) result in great developer productivity.   * Modularity: Only required dependencies were embedded, keeping applications    lean.   * Documentation: Well-organized, versioned documentation with working examples.   * Native Compilation: The ability to generate compact native binaries for    Kubernetes deployment.  Despite the strong competition from a vibrant JVM ecosystem, these advantages made Quarkus the preferred choice for exposing 5G APIs at Orange.   LESSONS LEARNED FROM ADOPTING QUARKUS   MIGRATION & DEVELOPMENT EXPERIENCE  Transitioning from Spring to Quarkus was not overly complex, especially for those familiar with JAX-RS / Jakarta REST.  The significantly enhanced productivity in dev and test modes, but required careful consideration for their CI/CD environments, where no container runtime is available.  The modular approach ensured applications remained lightweight but introduced a large number of small dependencies to manage.   SPEC-FIRST API DEVELOPMENT  As spec-first practitioners, integrating OpenAPI specification generation was a crucial requirement that Quarkus handled effectively.   JAVA & KOTLIN INTEROPERABILITY  While Quarkus supports Kotlin, writing full Kotlin extensions proved challenging at times. The team retained some Java code, and Java-Kotlin interoperability worked smoothly.   NATIVE COMPILATION & PERFORMANCE  Native compilation produced compact native executables, but the process of producing them was lengthy. The team reserved it for the final build stage when absolutely necessary.  Some fine-tuning was required to prevent class pruning issues.  When building native executables, the call tree is analyzed to determine which classes and methods are used. Everything that is not used is pruned to reduce the size of the executable and the RSS usage.  In some cases, e.g. when using reflection, you will have to declare explicitly that a class is used so that it ends up being included in the native executable.  Quarkus provides tooling to simplify this configuration.   REACTIVE PROGRAMMING & MUTINY  Having worked extensively with Reactor, the transition to Mutiny had a learning curve.  While effective and more intuitive thanks to its navigable API, it was perceived as more verbose for the simple cases.   ARCHITECTURE OVERVIEW  Orange designed a microservices-based architecture to expose 5G APIs efficiently.   MICROSERVICES & API WRAPPERS  Each API wrapper was implemented as a dedicated microservice for better version control. The team leveraged Reactive APIs wherever possible, since there are a lot of time-consuming asynchronous tasks to be performed on the core network side and saving resources is a business goal.   CI/CD & DEPLOYMENT  Each microservice had its own GitLab repository with an independent build pipeline for its Docker image.  Renovate was used to automate dependency upgrades. A dedicated deployment project pushed new Docker images to an OpenShift cluster using Kustomize + ArgoCD.   INFRASTRUCTURE COMPONENTS  Additional services included:   * Vault for secrets management   * Redis for caching   * Neo4j for database operations   * Kafka for messaging  Vert.x HTTP Proxy was used for routing and backend protection.   RESULTS & IMPACT  After implementing Quarkus in production, Orange successfully deployed ten APIs across various 4G/5G network cores. Over time, the team performed multiple Quarkus version upgrades (2.11 → 3.14), all well-managed through Renovate with minimal code adaptation—except for necessary adjustments during the migration to Jakarta EE."
+  "content": "INTRODUCTION  Single-page application (SPA) runs in the browser and uses to log-in users, without depending on Quarkus OIDC. When the authentication is complete, SPA sends the access token to access Quarkus on behalf of the authenticated user.  Have a look at the simple diagram showing how this process works, copied to this post from the :    As illustrated in the picture above, the OIDC provider authenticates the current user, SPA receives ID and access tokens and uses the access token to access the Quarkus endpoint.  The security challenge that the OAuth2 experts have been trying to address is how to prove that the client such as SPA which is sending the token actually owns this token ? There is nothing in the HTTP Authorization: Bearer <token> header that proves that SPA did not leak the token.  Two specifications for sender-constraining access tokens have emerged over the years, and .   MUTUAL TLS CLIENT AUTHENTICATION AND CERTIFICATE-BOUND ACCESS TOKENS  specification describes how access tokens can be cryptographically bound to the MTLS client certificate.  By proving that the access token is bound to the client certificate, the Quarkus application can get a high degree of confidence that the current access token is constrained to, owned by the client which authenticated to Quarkus over MTLS.    Implementing the cryptographic binding is not complex in this case. The current access token is expected to contain a confirmation with the SHA-256 certificate thumbprint and it must match the thumbprint of the current MTLS client certificate. If the token is in JWT format, then it must include a confirmation claim. If the token is binary then the confirmation must be included in the remote token introspection response.  Such a binding can only be successful if the OpenId Connect provider has access to the same client certificate which is used during the MTLS authentication to Quarkus.  The downside of using the MTLS token binding is that correctly configuring the OpenId Connect provider, ensuring that browsers can request an X509 certiticate authentication when SPA redirects the user to authenticate to the OIDC provider is complex.  If you are a Keycloak user, check the in the Advanced Configuration section of the and the community blog post.  As far as Quarkus is concerned, you only need to set a single OIDC configuration property, quarkus.oidc.token.binding.certificate=true, in addition to the Vert.x HTTP MTLS configuration, to enforce the MTLS token binding.  See the documentation for more details.   DEMONSTRATING PROOF-OF-POSSESSION (DPOP)  specification describes how access tokens can be cryptographically bound to special JWT tokens called DPoP proofs.    The SPA client generates a private and public key pair, and creates a DPoP proof token to complete the access token acquisition from the OIDC provider. It then forwards this DPoP token to Quarkus with a new DPoP proof. The access token must be bound to the DPoP proof by containing a public JSON Web Key (JWK) key thumbprint which matches the thumbprint of the public JWK key contained in the DPoP proof.  This binding can only be successful if the client uses the same public and private key pair for creating the DPoP proof to request the access token in the previous step and creating another DPoP proof for submitting it alongside the DPoP access token to Quarkus.  Quarkus OIDC will also enforce . Support for custom is also planned.  Adoption of DPoP, compared to that of the MTLS token binding, is expected to progress faster, because DPoP is an application-level protocol, with no expectation that the transport-level MTLS authentication takes place. However, correctly creating DPoP proofs at the SPA level is not straightforward and requires care.  If you are a Keycloak user, then enabling an experimental dpop feature is sufficient to get started. Also check the in the Advanced Configuration section of the and the community blog post.  As far as Quarkus is concerned, you only need to set a single OIDC configuration property, quarkus.oidc.token.authorization-scheme=dpop to accept DPoP tokens and enforce their binding to the accompanying DPoP proofs.  See the documentation for more details.   FINANCIAL-GRADE API (FAPI)  is a general high-security API profile built on top of OAuth2.  Both and specifications are included in the Financial-Grade API 2.0 .   CONCLUSION  In this article, we have discussed two important OAuth2 specifications for sender-constraining access tokens, and .  Both of these token security elevation technologies can be easily supported in Quarkus OIDC, by using a single configuration property only, without having to write a lot of custom code and configuration.  Please experiment with and in Quarkus and let us know what you think."
 }