Red Hat Data Grid is an in-memory data service you can use to speed up your applications. Red Hat's single sign-on technology (SSO) provides a convenient way to connect to Data Grid. Normally, SSO is used with Secure Sockets Layer (SSL), as I explained in my previous article. But if this layer of security is not needed, you can use SSO between your application and Red Hat Data Grid without SSL. This article shows how to integrate Data Grid and SSO into Red Hat OpenShift without SSL.
This integration of Data Grid and SSO with SSL communication disabled is suitable for test scenarios, where it can be used to set up an environment quickly and carry out tests to understand how Data Grid can be used as a remote store with SSO.
Note: All the cross-site replication use cases between Red Hat Data Grid and Red Hat's single sign-on technology are in tech preview. Thus, the material in this article does not make use of a cross-site replication use case and is not recommended for production use. This article employs Data Grid as a remote store with SSO, which also requires proper performance tuning and would require a support exception in order to engage Red Hat technical support.
Prerequisites
The minimum versions for the technologies used in this article follow:
- The current version of the oc command-line interface (CLI)
- Red Hat Data Grid 8.2
- Red Hat's single sign-on technology 7.5
- Red Hat OpenShift 4.6
Deploying the data grid
You can use Red Hat Data Grid by installing the Data Grid Operator from Red Hat's OperatorHub.io. The process is similar to the one described in the "Setting up Data Grid"" section of my previous article:
$ oc project dg
$ oc get po
NAME READY STATUS RESTARTS AGE infinispan-operator-new-deploy-68fbd6d495-9n9lt 1/1 Running 0 58s
Creating an Infinispan cluster
Installing the Data Grid Operator leads to the creation of an Infinispan cluster. We are not using SSL in our setup, so you must disable SSL by configuring the Infinispan cluster to be created with a endpointEncryption type of none under the security entry:
apiVersion: infinispan.org/v1
kind: Infinispan
metadata:
name: rhsso-infinispan
namespace: dg
spec:
security:
endpointEncryption:
type: None
service:
type: DataGrid
replicas: 2
Creating the Data Grid route
You need to create an OpenShift route to the Data Grid console in order to get access to the console. You can do so by following these menu items in the OpenShift console:
Networking→Routes→Create Route→Name (a unique name for the route within the project)→Hostname (optional)→Service (select the service, which has the same name as the Infinispan cluster)→Target Port (11222)→Create
You now have a route without TLS (the modern implementation of SSL). View the route as follows:
$ oc get routes
NAME HOST/PORT PATH SERVICES PORT TERMINATION WILDCARD
dg1 dg1-dg.apps.varsha.lab.upshift.rdu2.redhat.com rhsso-infinispan infinispan None
To get access to the console via the route, you need to retrieve the developer credentials from the operator generated by the secret:
$ oc get secret rhsso-infinispan-generated-secret \
-o jsonpath="{.data.identities\.yaml}" | base64 --decode
Creating Infinispan caches
Caches required by SSO are created in Data Grid's Infinispan cluster. The Infinispan caches on the Red Hat Single Sign-On side use a remoteStore configuration (which in turn uses the Hot Rod protocol to store data on Infinispan clusters) to offload data to a Data Grid cluster. In this use case, the Data Grid cluster is in a separate namespace that replicates the offloaded data from SSO to the Infinipan cluster to ensure that the data is backed up.
You should create the following caches:
sessionsofflineSessionsclientSessionsofflineClientSessionsloginFailuresactionTokenswork
SSO uses a separate Infinispan cache called authenticationSessions to save data during each user's authentication. Requests from this cache usually involve only a browser and the SSO server, not the application. Here you can rely on sticky sessions and you don't have to replicate the authenticationSessions cache content to your Data Grid cluster.
Caches can be created via the operator using the Cache custom resource (CR). This feature is in tech preview, and therefore is not ready for production use. This CR also has some limitations. For example, the Cache CR provides a one-way mapping. Therefore, the CR cannot be edited after its creation, and deleting a CR doesn't update the server. If you want to change the configuration after creating the CR, you must tear down the Infinispan cluster and start over.
Caches can also be created through the CLI or the Data Grid console. To create a cache via the Data Grid console, follow these menu items:
Access the Data Grid Console (access via route)→Data Container→Create Cache→Provide Cache Name→Provide configuration
A work cache configuration would look like the following:
<infinispan><cache-container><replicated-cache name="work" statistics="true" mode="SYNC"
start="EAGER"><transaction mode="NONE" locking="PESSIMISTIC"/><locking
acquire-timeout="0" /></replicated-cache></cache-container></infinispan>
Similar configurations are created when you create the sessions, offlineSessions, clientSessions, offlineClientSessions, loginFailures, and actionTokens caches.
Deploying SSO in a different namespace
To deploy SSO, follow the steps in the "Deploying the SSO image" section of my previous article. Then, make two changes to the sso-extensions.cli file. First, put the Data Grid service name in the outbound socket binding:
Format of host : $DG_SERVICE_NAME.NAMESPACE.svc.cluster.local
Also, add the following Hot Rod property:
infinispan.client.hotrod.use_ssl=false
The sso-extension.cli configuration file should have the following content:
$ embed-server --std-out=echo --server-config=standalone-openshift.xml
batch
# Add the org.keycloak.keycloak-model-infinispan module to the keycloak cache container in the Infinispan subsystem.
/subsystem=infinispan/cache-container=keycloak:write-attribute(name=module,value=org.keycloak.keycloak-model-infinispan)
# Create a socket binding that points to Data Grid cluster in different namespace
/socket-binding-group=standard-sockets/remote-destination-outbound-socket-binding=remote-cache/:add(host=rhsso-infinispan1.rdrhsso.svc.cluster.local,port=${remote.cache.port:11222},fixed-source-port=true)
run-batch
batch
# Work cache is created as a replicated cache. The work cache itself does not cache any real data. It is used only for sending invalidation messages between cluster nodes
/subsystem=infinispan/cache-container=keycloak/replicated-cache=work/store=remote:add(cache=work,remote-servers=[remote-cache],fetch-state=false,passivation=false,preload=false,purge=false,shared=true,properties={rawValues=true,remoteStoreSecurityEnabled=true,marshaller=org.keycloak.cluster.infinispan.KeycloakHotRodMarshallerFactory,infinispan.client.hotrod.auth_username=developer,infinispan.client.hotrod.auth_password=NsldmxyQiVlh6kZY,infinispan.client.hotrod.use_ssl=false,infinispan.client.hotrod.auth_realm=default,infinispan.client.hotrod.auth_server_name=infinispan,infinispan.client.hotrod.protocol_version=2.9,infinispan.client.hotrod.use_auth=true})
# Other caches can be created as a distributed cache
/subsystem=infinispan/cache-container=keycloak/distributed-cache=sessions/store=remote:add(cache=sessions,remote-servers=[remote-cache],fetch-state=false,passivation=false,preload=false,purge=false,shared=true,properties={rawValues=true,marshaller=org.keycloak.cluster.infinispan.KeycloakHotRodMarshallerFactory,infinispan.client.hotrod.auth_username=developer,infinispan.client.hotrod.auth_password=NsldmxyQiVlh6kZY,infinispan.client.hotrod.use_ssl=false,infinispan.client.hotrod.auth_realm=default,infinispan.client.hotrod.auth_server_name=infinispan,infinispan.client.hotrod.protocol_version=2.9,infinispan.client.hotrod.use_auth=true})
/subsystem=infinispan/cache-container=keycloak/distributed-cache=offlineSessions/store=remote:add(cache=offlineSessions,remote-servers=[remote-cache],fetch-state=false,passivation=false,preload=false,purge=false,shared=true,properties={rawValues=true,marshaller=org.keycloak.cluster.infinispan.KeycloakHotRodMarshallerFactory,infinispan.client.hotrod.auth_username=developer,infinispan.client.hotrod.auth_password=NsldmxyQiVlh6kZY,infinispan.client.hotrod.use_ssl=false,infinispan.client.hotrod.auth_realm=default,infinispan.client.hotrod.auth_server_name=infinispan,infinispan.client.hotrod.protocol_version=2.9,infinispan.client.hotrod.use_auth=true})
/subsystem=infinispan/cache-container=keycloak/distributed-cache=clientSessions/store=remote:add(cache=clientSessions,remote-servers=[remote-cache],fetch-state=false,passivation=false,preload=false,purge=false,shared=true,properties={rawValues=true,marshaller=org.keycloak.cluster.infinispan.KeycloakHotRodMarshallerFactory,infinispan.client.hotrod.auth_username=developer,infinispan.client.hotrod.auth_password=NsldmxyQiVlh6kZY,infinispan.client.hotrod.use_ssl=false,infinispan.client.hotrod.auth_realm=default,infinispan.client.hotrod.auth_server_name=infinispan,infinispan.client.hotrod.protocol_version=2.9,infinispan.client.hotrod.use_auth=true})
/subsystem=infinispan/cache-container=keycloak/distributed-cache=offlineClientSessions/store=remote:add(cache=offlineClientSessions,remote-servers=[remote-cache],fetch-state=false,passivation=false,preload=false,/var/run/secrets/kubernetes.iopurge=false,shared=true,properties={rawValues=true,marshaller=org.keycloak.cluster.infinispan.KeycloakHotRodMarshallerFactory,infinispan.client.hotrod.auth_username=developer,infinispan.client.hotrod.auth_password=NsldmxyQiVlh6kZY,infinispan.client.hotrod.use_ssl=false,infinispan.client.hotrod.auth_realm=default,infinispan.client.hotrod.auth_server_name=infinispan,infinispan.client.hotrod.protocol_version=2.9,infinispan.client.hotrod.use_auth=true})
/subsystem=infinispan/cache-container=keycloak/distributed-cache=loginFailures/store=remote:add(cache=loginFailures,remote-servers=[remote-cache],fetch-state=false,passivation=false,preload=false,purge=false,shared=true,properties={rawValues=true,marshaller=org.keycloak.cluster.infinispan.KeycloakHotRodMarshallerFactory,infinispan.client.hotrod.auth_username=developer,infinispan.client.hotrod.auth_password=NsldmxyQiVlh6kZY,infinispan.client.hotrod.use_ssl=false,infinispan.client.hotrod.auth_realm=default,infinispan.client.hotrod.auth_server_name=infinispan,infinispan.client.hotrod.protocol_version=2.9,infinispan.client.hotrod.use_auth=true})
/subsystem=infinispan/cache-container=keycloak/distributed-cache=actionTokens/store=remote:add(cache=actionTokens,remote-servers=[remote-cache],fetch-state=false,passivation=false,preload=false,purge=false,shared=true,properties={rawValues=true,marshaller=org.keycloak.cluster.infinispan.KeycloakHotRodMarshallerFactory,infinispan.client.hotrod.auth_username=developer,infinispan.client.hotrod.auth_password=NsldmxyQiVlh6kZY,infinispan.client.hotrod.use_ssl=false,infinispan.client.hotrod.auth_realm=default,infinispan.client.hotrod.auth_server_name=infinispan,infinispan.client.hotrod.protocol_version=2.9,infinispan.client.hotrod.use_auth=true})
run-batch
reload
quit
To finish the procedure, follow steps 8 through 10 in the "Deploying the SSO image" section of my previous article. These steps create a config map named jboss-cli using the sso-extensions.cli file and mount that config map as a volume.
You can verify your integration using the tests in the "Verifying the integration" section of my previous article.
Here Data Grid and SSO are deployed in different namespaces, whereas the previous article deployed both in the same namespace.
Conclusion
This article has shown that Red Hat Data Grid and Red Hat's single sign-on technology are flexible and can work together in different ways to provide high-speed computing. Try out Data Grid today.