Brac POC — jboss-chat app

Two-user chat application for the bank-employees division, delivered through GitLab, Jenkins, Trivy, Nexus, and OpenShift GitOps. It uses WSO2 Identity Server and API Manager, a BFF, VM Kafka and Redis, canary frontends, and a JBoss/WildFly managed-domain backend topology.

Delivered-state page for the jboss-chat proof-of-concept. The app is a small bank-employees chat service for shaikat and zahid, built to show how a regulated Java workload can move through the existing bank toolchain and land on OpenShift with identity, API gateway enforcement, observability, and GitOps control.

At a glance

What got built

The main runtime path now prefers the managed-domain service:

Browser
  -> frontend-v1 or frontend-v2
  -> same-origin /api route
  -> BFF
  -> eap-domain group A on 8080
  -> eap-domain group B on 8230
  -> chat-backend fallback on 9080

Identity and API gateway

The login flow uses WSO2 Identity Server as the identity provider. The SPA is registered as a public OIDC client with PKCE enabled, and the redirect URI is the production callback route:

https://jboss-chat.apps.sub.comptech-lab.com/callback

The frontend calls the WSO2 API Manager gateway base path:

https://gateway.apps.sub.comptech-lab.com/jboss-chat/1.0.0

The BFF validates bearer tokens again by loading the WSO2 JWKS endpoint. It allows only the expected demo users and group:

JBoss managed-domain topology

The app includes a managed-domain backend image to match the requested JBoss EAP operational model. In the lab it runs as a single OpenShift pod containing:

This is intentionally a lab-sized implementation of the domain pattern. A production HA version should split controllers and hosts across pods or nodes, then add backup domain-controller behavior and persistent management state.

Kafka and Redis

The app uses the existing VM middleware rather than deploying new Kafka or Redis inside OpenShift.

Kafka receives message events. Redis is used for notification fan-out. Both are allowed by the tenant NetworkPolicy only on the required VM ports.

Observability

The app follows the cluster’s OpenShift observability model:

The tenant NetworkPolicy allows the app to reach the platform OpenTelemetry collector in the tracing namespace and allows user-workload monitoring to scrape the metrics endpoints.

Pipeline and controls

The delivery flow is deliberately plain:

The managed-domain image was updated to a current WildFly base and the unused Artemis server module was removed from that image so the Trivy critical scan passes while preserving the domain-controller and server-group topology.

Current live status

As of the last review:

Residual work

The core app is live, but these items should be treated as follow-up hardening:

• Split the JBoss managed-domain controllers and host controllers into a more production-like HA shape.
• Replace the shared app-default Redis ACL user with a workload-specific jboss-chat Redis ACL user.
• Add Kafka TLS/SASL and app-specific Kafka ACLs.
• Decide whether SigNoz must be the terminal store for traces and metrics, or whether the OpenShift platform collector and Tempo/User Workload Monitoring path is the accepted OpenShift-native endpoint.
• Add an automated browser login smoke test for shaikat and zahid once the demo credentials are promoted into a test-runner secret.