Direct LDAP gives Data Grid a smaller authentication architecture on OpenShift

Red Hat has published a hands-on pattern for connecting Red Hat Data Grid directly to LDAP or LDAPS on OpenShift, giving platform teams an alternative to putting a full single sign-on layer between applications and the directory. The walkthrough is the second part of an authentication series and covers the deployment, operator configuration and encryption choices needed to make the direct-binding model work.

What the pattern changes

The architecture removes an identity-provider hop. Data Grid authenticates users against the directory through an LDAP realm configured in its server security settings. Red Hat’s example deploys OpenLDAP in a dedicated OpenShift namespace, creates a custom Data Grid configuration through a ConfigMap and attaches that configuration to an Infinispan custom resource.

The useful part is not the test directory itself; it is the operator integration. The example shows the directory URL, bind principal, credential, timeouts, connection pooling and identity mapping in one configuration. It also demonstrates group lookup through attribute mapping, so directory membership can become Data Grid authorization data.

Where LDAPS matters

Red Hat is explicit about the transport boundary: pod-to-pod traffic inside a cluster is not automatically encrypted merely because it stays inside OpenShift. Teams using direct LDAP therefore need either LDAPS or another mechanism such as OpenShift Service CA encryption if directory credentials and authentication exchanges must be protected in transit.

The guide builds LDAPS on top of the same LDAP configuration by adding TLS materials and trust configuration. That makes the operational choice clearer: plain LDAP can be useful for local validation, but the production design has to account for certificate issuance, trust distribution and rotation.

Who should use it

Direct binding fits teams that need centralized directory authentication but do not need the additional protocols, federation features or administrative surface of Keycloak. It keeps the Data Grid authentication path lean and leaves fewer components to run.

That simplicity is also the tradeoff. A Keycloak-based design centralizes SSO and brokering across applications; direct LDAP couples Data Grid more closely to the directory and moves directory schema, group mapping and TLS lifecycle into the Data Grid deployment. Platform teams should choose between the two based on the wider identity architecture, not merely on which configuration is shorter.

What to try

Start with the isolated OpenLDAP example only as a validation environment. Then replace its directory URL, bind account and identity mapping with production equivalents, enable encrypted transport, and test both user authentication and group-derived authorization before exposing Data Grid outside its namespace. The article links the companion Keycloak design, making the two patterns directly comparable before teams commit to an operating model.