Data Grid’s Keycloak migration is an authentication-flow redesign

Red Hat has published an end-to-end OpenShift pattern for delegating Data Grid authentication to Red Hat build of Keycloak 26. The walkthrough is more than an operator installation recipe: it separates the browser-facing login client from Data Grid’s server-side token validation and shows what changes for teams moving from the retired Red Hat Single Sign-On product line.

Two clients, two jobs

The design gives the Data Grid console a public OpenID Connect client for browser redirects and standard authorization flow. A second, confidential client belongs to the Data Grid server and carries the secret used for OAuth 2.0 token introspection. Data Grid sends access tokens to Keycloak’s introspection endpoint and checks that they remain active before granting access.

That split avoids forcing one client configuration to serve incompatible trust models. The browser client does not hold a secret, while the server client can authenticate to the introspection endpoint. The imported Keycloak realm also defines Data Grid-oriented roles—including administrative, application, observer and monitoring access—and assigns example users to them.

The OpenShift deployment boundary

Red Hat deploys Keycloak through its version 26 operator, backs it with PostgreSQL and configures an external OpenShift route for browser traffic. Internal Data Grid-to-Keycloak calls use the cluster service, while the configured hostname and forwarded headers keep external redirects on the public HTTPS address.

The Data Grid side is supplied through Helm values. Its token realm names the public console client, the confidential introspection client and Keycloak endpoints; Data Grid’s endpoint then uses that realm for authentication. Red Hat’s verification flow sends a user from the Data Grid console to Keycloak and back to the console after successful login.

The details matter during migration. The article notes that Red Hat build of Keycloak has replaced Red Hat Single Sign-On, while retaining a comparison and a deprecated legacy configuration for teams still transitioning. It also calls out Keycloak 26 account requirements in the realm import: example users need profile fields and a verified email state or login can fail as an incompletely configured account.

What teams should decide

This pattern centralizes identity and roles in Keycloak instead of keeping credentials inside Data Grid. It suits environments that want browser SSO, shared identity administration or federation across applications. The companion direct-LDAP design is leaner when Data Grid alone needs directory-backed authentication.

Before migrating, platform teams should inventory both Data Grid clients, rotate the confidential client secret, map existing roles into the new realm and test internal introspection separately from browser redirects. Treating those as distinct paths makes failures easier to diagnose and keeps the migration from becoming a simple operator swap that leaves the authentication model implicit.