Good morning.
We are continuing to work on the integration and, although we have made progress on several points, we are still unable to get it to work properly. We have prepared and attached a detailed technical report with all the information (configuration, logs, and system analysis).
We would like to know if anyone in the community could: guide us with more specific instructions, or review the steps with us in a brief video call to identify what we are overlooking.
We greatly appreciate the effort and time of those who make this project possible.
Any support, clues, or shared experiences will be of great help in enabling us to
get unstuck and move forward.
Best regards.
Juan José
OpenMRS SSO Distribution
-
System
Analysis Report
Project Overview
This document provides a comprehensive analysis of the OpenMRS SSO distribution system,
detailing its architecture, configuration, and authentication flow. The project is designed to
provide a customized OpenMRS distribution with Single Sign-On (SSO) capabilities using
Keycloak for authentication.
Main Problem Statement
The primary issue with this project is that when accessing hhttp://localhost:80/openmrs/ spa (the frontend service), the system fails to properly authenticate users through the Keycloak
SSO process. The system should redirect to Keycloak at hhttp://localhost:8081 for Single
Sign-On authentication, but there are configuration issues preventing proper initialization and
user creation in Keycloak.
System Architecture
The system consists of multiple Docker containers orchestrated through docker-compose:
1 Backend: OpenMRS distribution with OAuth2, DataFilter modules, and custom user/
patient generation
2 Frontend: SPA frontend with OAuth2 login configuration
3 Database: MariaDB instance with initial OpenMRS dump
4 Keycloak: SSO authentication service for OpenMRS
5 Gateway: API gateway service managing routing between services
Technologies and Versions
•
OpenMRS Backend: openmrs/openmrs-reference-application-3-
backend:nightly
•
OpenMRS Frontend: openmrs/openmrs-reference-application-3-
frontend:nightly
Keycloak: .docker.io/bitnami/keycloak:24.0.3
•
•
Database: MariaDB 10.8.2
•
Gateway: Nginx Alpine
•
Docker Compose: Version 2.x
Additional configuration files (mounted as volumes for each container) have been taken from the
distro folder of the standard latest Ozone distribution.
Expected Behavior
The system should function as follows:
1 User accesses hhttp://localhost:8080/openmrs/spa
2 Frontend redirects to backend for authentication
3 Backend redirects to Keycloak SSO at hhttp://localhost:8081
4 User logs in with credentials from keycloak/users.csv (this steps is not yet reached given
this configuration state)
5 After successful authentication, user is redirected back to OpenMRS SPA
Simplified Docker Compose Infrastructure
services:
gateway:
image: nginx:alpine
ports:ports:
- “80:80”
- “443:443”
volumes:
- ./gateway/nginx.conf:/etc/nginx/nginx.conf
- ./gateway/ssl:/etc/nginx/ssl
frontend:
image: openmrs/openmrs-reference-application-3-frontend:nightly
environment:
SPA_PATH: /openmrs/spa
API_URL: /openmrs
OPENMRS_PUBLIC_URL: hhttp://localhost:8080
volumes:
- ./frontend/oauth2.json:/usr/share/nginx/html/oauth2.json:ro
depends_on:
- backend
backend:
image: openmrs/openmrs-reference-application-3-backend:nightly
environment:
OMRS_CONFIG_MODULE_WEB_ADMIN: “true”
OMRS_CONFIG_AUTO_UPDATE_DATABASE: “true”
OMRS_CONFIG_CREATE_TABLES: “true”
OMRS_CONFIG_CONNECTION_SERVER: mysql
OMRS_CONFIG_DATABASE: mysql
OMRS_CONFIG_CONNECTION_DRIVER_CLASS: com.mysql.cj.jdbc.Driver
OMRS_CONFIG_CONNECTION_DATABASE: openmrs
OMRS_CONFIG_CONNECTION_USERNAME: ${OMRS_DB_USER:-openmrs}
OMRS_CONFIG_CONNECTION_PASSWORD: ${OMRS_DB_PASSWORD:-openmrs}
HOST_URL: ${SERVER_SCHEME}://${O3_HOSTNAME}
OAUTH2_ENABLED: ${ENABLE_SSO}
KEYCLOAK_URL: ${SERVER_SCHEME}://${KEYCLOAK_HOSTNAME}
OPENMRS_CLIENT_UUID: ${OPENMRS_CLIENT_UUID}
OMRS_OAUTH_CLIENT_SECRET: ${OPENMRS_CLIENT_SECRET}
OPENMRS_CLIENT_SECRET: ${OPENMRS_CLIENT_SECRET}
healthcheck:
test: [ “CMD”, “curl”, “-f”, "hhttp://localhost:8080/openmrs/
health/started" ]
volumes:
- “${OPENMRS_DATA:-openmrs-data}:/openmrs/data:rw”
- "${OPENMRS_CONFIG_SERVER_PATH}/modules:/openmrs/distribution/
openmrs_modules/"
- "${OPENMRS_CONFIG_PATH}/initializer_config:/openmrs/
distribution/openmrs_config"
- “${OPENMRS_CONFIG_PATH}/properties:/etc/properties/”
- "${OPENMRS_CONFIG_PATH}/properties/fhirproxy.properties:/
openmrs/data/fhirproxy/config.properties"
- "${OPENMRS_CONFIG_PATH}/properties/oauth2.properties:/openmrs/
data/oauth2.properties"
- "${OPENMRS_CONFIG_SERVER_PATH}/server.xml:/usr/local/tomcat/
conf/server.xml"
mysql:image: mariadb:10.8.2
ports:
- “3306:3306”
environment:
MYSQL_DATABASE: openmrs
MYSQL_USER: ${OMRS_DB_USER:-openmrs}
MYSQL_PASSWORD: ${OMRS_DB_PASSWORD}
MYSQL_ROOT_PASSWORD: ${MYSQL_ROOT_PASSWORD}
OPENMRS_DB_NAME: openmrs
OPENMRS_DB_USER: ${OMRS_DB_USER:-openmrs}
OPENMRS_DB_PASSWORD: ${OMRS_DB_PASSWORD}
volumes:
- “${MYSQL_DATADIR:-postgresql-data}:/var/lib/mysql”
- "${SQL_SCRIPTS_PATH}/mysql/create_db.sh:/docker-entrypoint-
initdb.d/create_db.sh"
- "${SQL_SCRIPTS_PATH}/mysql/openmrs:/docker-entrypoint-initdb.d/
db/openmrs"
keycloak:
image: docker..io/bitnami/keycloak:24.0.3
restart: unless-stopped
volumes:
- ${KEYCLOAK_CONFIG_PATH}/realms:/keycloak-files/realm-config
- ${KEYCLOAK_CONFIG_PATH}/themes/carbon:/opt/bitnami/keycloak/
themes/carbon
ports:
- “8080:8081”
environment:
KC_BOOTSTRAP_ADMIN_USERNAME: ${KC_ADMIN_USER}
KC_BOOTSTRAP_ADMIN_PASSWORD: ${KC_ADMIN_PASSWORD}
KEYCLOAK_ADMIN_PASSWORD: ${KC_ADMIN_PASSWORD}
KEYCLOAK_ADMIN: ${KC_ADMIN_USER}
PROXY_ADDRESS_FORWARDING: “true”
KC_PROXY: reencrypt
KC_HOSTNAME_STRICT_BACKCHANNEL: “true”
KEYCLOAK_AUTH_SERVER_URL: ${AUTH_SERVER_URL}
OMRS_OAUTH_CLIENT_SECRET: ${OMRS_OAUTH_CLIENT_SECRET}
OMRS_FRONTCHANNEL_LOGOUT_URI: ${OMRS_FRONTCHANNEL_LOGOUT_URI}
USERS_DEFAULT_PASSWORD: ${USERS_DEFAULT_PASSWORD}
KC_HOSTNAME_STRICT: false
KC_HOSTNAME_STRICT_HTTPS: false
KEYCLOAK_ENABLE_HTTPS: false
KC_HTTP_ENABLED: true
KC_HTTP_PORT: 8081
KC_HOSTNAME: localhost:8081
KC_HEALTH_ENABLED: ‘true’
KC_METRICS_ENABLED: ‘true’
KC_DB: postgres
KC_DB_URL: jdbc:postgresql://postgresql:5432/${KEYCLOAK_DB}
KC_CACHE: local
KC_CACHE_STACK: tcp
KEYCLOAK_DATABASE_NAME: ${KEYCLOAK_DB}
KC_DB_USERNAME: ${KEYCLOAK_DB_USER}
KC_DB_PASSWORD: ${KEYCLOAK_DB_PASSWORD}KEYCLOAK_DATABASE_SCHEMA: ${KEYCLOAK_DB_SCHEMA}
KEYCLOAK_CREATE_ADMIN_USER: “true”
KEYCLOAK_EXTRA_ARGS_PREPENDED: "–spi-login-protocol-openid-
connect-legacy-logout-redirect-uri=true"
KEYCLOAK_EXTRA_ARGS: "
-Dkeycloak.profile.feature.scripts=enabled
-Dkeycloak.migration.action=import
-Dkeycloak.migration.provider=dir
-Dkeycloak.migration.dir=/keycloak-files/realm-config
-Dkeycloak.migration.strategy=OVERWRITE_EXISTING"
postgresql:
command: "postgres -c wal_level=logical -c max_wal_senders=10 -c
max_replication_slots=10 -c max_connections=200"
image: postgres:13
environment:
POSTGRES_DB: postgres
POSTGRES_USER: ${POSTGRES_USER}
POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
ODOO_DB_NAME: ${ODOO_DATABASE}
ODOO_DB_USER: ${ODOO_DB_USER}
ODOO_DB_PASSWORD: ${ODOO_DB_PASSWORD}
KEYCLOAK_DB: ${KEYCLOAK_DB}
KEYCLOAK_DB_SCHEMA: ${KEYCLOAK_DB_SCHEMA}
KEYCLOAK_DB_USER: ${KEYCLOAK_DB_USER}
KEYCLOAK_DB_PASSWORD: ${KEYCLOAK_DB_PASSWORD}
ports:
- “5432:5432”
volumes:
- “${POSTGRES_DATADIR:-postgresql-data}:/var/lib/postgresql/data”
- "${SQL_SCRIPTS_PATH}/postgresql/create_db.sh:/docker-
entrypoint-initdb.d/create_db.sh"
- "${SQL_SCRIPTS_PATH}/postgresql/odoo:/docker-entrypoint-
initdb.d/db/odoo"
- "${SQL_SCRIPTS_PATH}/postgresql/keycloak:/docker-entrypoint-
initdb.d/db/keycloak"
Current State Analysis
System Status
The system is currently operational but funtionally has some configuration issues that need to be
addressed:
•
All containers are running successfully
•
The gateway correctly routes requests to frontend/backend services
•
Authentication flow does NOT work end-to-end with proper redirects
•
Keycloak health endpoint returns 200, confirming realm is accessible
•
Users are created as shown in logs (if instructed to do so)
Key Configuration Files
Environment Variables (.env-new)
KEYCLOAK_CONFIG_PATH=./distro/configs/keycloak
SQL_SCRIPTS_PATH=./distro/data
OPENMRS_CONFIG_PATH=./distro/configs/openmrs
OPENMRS_CONFIG_SERVER_PATH=./distro/binaries/openmrsOPENMRS_CONFIG_SERVER_PATH=./distro/binaries/openmrs
…
[email protected]
KC_ADMIN_PASSWORD=whatever
USERS_DEFAULT_PASSWORD=password
Authentication Flow Analysis
Step-by-Step Call Order Workflow
1 User Access: User visits hhttp://localhost:8080/openmrs/spa
2 Gateway Routing: Gateway routes to frontend service on port 80
3 Frontend Authentication: Frontend redirects to backend for authentication
4 Backend Redirect: Backend redirects to Keycloak SSO at hhttp://localhost:8081
5 Keycloak Authentication: User authenticates with Keycloak
6 Redirect Back: Successful authentication redirects back to OpenMRS SPA
Authentication Flow Verification
The system works correctly as demonstrated by:
•
Gateway returns 301 redirect indicating proper routing
•
Keycloak health endpoint returns 200 status code
•
Authentication flow does NOT work end-to-end with proper redirects
•
Users are created in Keycloak as shown in logs
Issues Identified
1. Volume Mounting Configuration Issue
Problem: The Keycloak configuration files are not being properly mounted into the container.
Evidence:
# From docker inspect output:
“Mounts”:
# Logs show connection issues:
Failed to send request - Connect to keycloak:8081 [keycloak/172.18.0.2]
failed: Connection refused
Root Cause: The volume mount path ./distro/configs/keycloak is not being resolved
correctly in the Docker environment.
2. Keycloak Initialization Timing Issues
Problem: The initialization script attempts to connect to Keycloak before it’s fully ready.
Evidence from logs:
Failed to send request - Connect to keycloak:8081 [keycloak/172.18.0.2]
failed: Connection refused
…
Created new user with id ‘16891ff5-a750-413c-9c37-8c68996cf07a’
INFO: Created REALM master
Root Cause: The initialization script runs before Keycloak is fully initialized, but eventually
succeeds.
3. User Creation Verification
Evidence of successful user creation:Evidence of successful user creation:
Created new user with id ‘16891ff5-a750-413c-9c37-8c68996cf07a’
Created new user with id ‘2aa3e350-9714-4f4a-bbdf-3b7a07123ef6’
…
Create username admin with email [email protected]
Create username clerk.l1 with email [email protected]
Technical Details
Working Components
1 Gateway Configuration:
◦
Correctly routes to frontend/backend services
◦
Properly configured proxy_pass for Keycloak on port 8081
2 Keycloak Service:
◦
Running on port 8081 (mapped from container port 8081)
◦
Health endpoint accessible at hhttp://localhost:8081/realms/master
3 Authentication Flow:
◦
SPA frontend loads correctly
◦
Redirects to backend for authentication
◦
Backend properly redirects to Keycloak SSO
◦
Successful login redirects back to SPA (not yet tested to work)
Configuration Files
Keycloak Realm File Location
•
•
Contains user definitions and realm configuration
Environment Variables
Path: distro/configs/keycloak/realms/main-realm.json (89,842 bytes)
• KEYCLOAK_CONFIG_PATH=./distro/configs/keycloak - Points to realm
configuration directory
• [email protected] - Admin credentials for Keycloak
• KC_ADMIN_PASSWORD=whatever - Default admin password
System Verification
Successful Authentication Flow Tests
1 Gateway Access Test:
curl -s -o /dev/null -w “%{http_code}” hhttp://localhost:8080/
openmrs/spa
2 # Returns 301 redirect indicating proper routing
3
4 Keycloak Health Check:
curl -s -o /dev/null -w “%{http_code}” hhttp://localhost:8081/
realms/master
5 # Returns 200, confirming realm is accessible
6
Issues Identified
1. Volume Mounting Configuration Issue
Problem: The Keycloak configuration files are not being properly mounted into the container.
Evidence:Evidence:
# From docker inspect output:
“Mounts”:
# Logs show connection issues:
Failed to send request - Connect to keycloak:8081 [keycloak/172.18.0.2]
failed: Connection refused
Root Cause: The volume mount path ./distro/configs/keycloak is not being resolved
correctly in the Docker environment.
Detailed Logs Analysis:
# Keycloak container logs show:
Logging into hhttp://keycloak:8081 as user [email protected] of realm
master
Failed to send request - Connect to keycloak:8081 [keycloak/172.18.0.2]
failed: Connection refused
No realm or token specified. Use --realm, --token, or 'kcadm.sh config
credentials’.
…
INFO: Created REALM master
Created new user with id ‘16891ff5-a750-413c-9c37-8c68996cf07a’
Created new user with id ‘2aa3e350-9714-4f4a-bbdf-3b7a07123ef6’
Impact: While users are eventually created, the realm configuration files are not being imported
properly during startup, which could cause issues with user definitions and authentication
settings.
2. Keycloak Initialization Timing Issues
Problem: The initialization script attempts to connect to Keycloak before it’s fully ready.
Evidence from logs:
# Multiple connection refused errors in initialization:
Failed to send request - Connect to keycloak:8081 [keycloak/172.18.0.2]
failed: Connection refused
…
Created new user with id ‘16891ff5-a750-413c-9c37-8c68996cf07a’
INFO: Created REALM master
Root Cause: The initialization script runs before Keycloak is fully initialized, but eventually
succeeds after retries.
Impact: This creates a race condition where the system may appear to work initially but could
have inconsistent state during startup.
3. Authentication Flow Problems
Problem: When accessing hhttp://localhost:80/openmrs/spa (the frontend service), the
system fails to properly authenticate users through the Keycloak SSO process.
Evidence:
# Gateway access test:
curl -s -o /dev/null -w “%{http_code}” hhttp://localhost:8080/openmrs/
spacurl -s -o /dev/null -w “%{http_code}” hhttp://localhost:8080/openmrs/
spa
# Returns 301 redirect indicating proper routing
# Keycloak health check:
curl -s -o /dev/null -w “%{http_code}” hhttp://localhost:8081/realms/
master
# Returns 200, confirming realm is accessible
Root Cause: While the system can be accessed and authentication seems to work, there are
configuration issues that prevent access using http protocol and forces instead https always
despite the initialization of Keycloak with realm files (using {sslRequired: none}).
Conclusion
Appendix A: System Logs Summary
Keycloak Initialization Logs
keycloak 05:25:10.63 INFO ==>
keycloak 05:25:10.63 INFO ==> Welcome to the Bitnami keycloak
container
keycloak 05:25:10.63 INFO ==> Subscribe to project updates by watching
keycloak 05:25:10.63 INFO ==> Submit issues and feature requests at
keycloak 05:25:10.63 INFO ==> Upgrade to Tanzu Application Catalog for
production environments to access custom-configured and pre-packaged
software components. Gain enhanced features, including Software Bill of
Materials (SBOM), CVE scan result reports, and VEX documents. To learn
more, visit Bitnami Secure Images
keycloak 05:25:10.63 INFO ==>
keycloak 05:25:10.65 INFO ==> ** Starting keycloak setup **
keycloak 05:25:10.66 INFO ==> Validating settings in KEYCLOAK_* env
vars…
keycloak 05:25:10.74 INFO ==> Trying to connect to PostgreSQL server
postgresql…
keycloak 05:25:10.78 INFO ==> Found PostgreSQL server listening at
postgresql:5432
keycloak 05:25:10.79 INFO ==> Configuring database settings
keycloak 05:25:10.81 INFO ==> Enabling statistics
keycloak 05:25:10.81 INFO ==> Enabling health endpoints
keycloak 05:25:10.81 INFO ==> Configuring http settings
keycloak 05:25:10.83 INFO ==> Configuring hostname settings
keycloak 05:25:10.84 INFO ==> Configuring cache count
keycloak 05:25:10.85 INFO ==> Configuring log level
keycloak 05:25:10.91 INFO ==> Configuring proxy
keycloak 05:25:10.94 INFO ==> ** keycloak setup finished! **
keycloak 05:25:10.96 INFO ==> ** Starting keycloak **
Updating the configuration and installing your custom providers, if
any. Please wait.
2025-09-02 05:25:14,175 WARN [org.key.qua.run.cli.Picocli] (main) The
following used options or option values are DEPRECATED and will be
removed in a future release:
- proxy: Use proxy-headers.
Consult the Release Notes for details.
2025-09-02 05:25:14,221 INFO [org.key.com.Profile] (main) Preview
features enabled: scripts:v12025-09-02 05:25:14,221 INFO [org.key.com.Profile] (main) Preview
features enabled: scripts:v1
2025-09-02 05:25:16,282 INFO [org.key.com.Profile] (main) Preview
features enabled: scripts:v1
2025-09-02 05:25:18,382 WARN [org.key.services] (build-32) KC-
SERVICES0047: metrics
(org.jboss.aerogear.keycloak.metrics.MetricsEndpointFactory) is
implementing the internal SPI realm-restapi-extension. This SPI is
internal and may change without notice
2025-09-02 05:25:19,377 WARN [org.key.services] (build-32) KC-
SERVICES0047: metrics-listener
(org.jboss.aerogear.keycloak.metrics.MetricsEventListenerFactory) is
implementing the internal SPI eventsListener. This SPI is internal and
may change without notice
2025-09-02 05:25:29,462 INFO [io.qua.dep.QuarkusAugmentor] (main)
Quarkus augmentation completed in 13812ms
2025-09-02 05:25:31,831 WARN
[org.keycloak.quarkus.runtime.cli.Picocli] (main) The following used
options or option values are DEPRECATED and will be removed in a future
release:
- proxy: Use proxy-headers.
Consult the Release Notes for details.
2025-09-02 05:25:32,204 INFO [org.keycloak.common.Profile] (main)
Preview features enabled: scripts:v1
2025-09-02 05:25:34,010 WARN [org.infinispan.CONFIG] (keycloak-cache-
init) ISPN000569: Unable to persist Infinispan internal caches as no
global state enabled
2025-09-02 05:25:34,095 INFO [org.infinispan.CONTAINER] (keycloak-
cache-init) ISPN000556: Starting user marshaller
‘org.infinispan.jboss.marshalling.core.JBossUserMarshaller’
2025-09-02 05:25:34,855 WARN
[org.keycloak.protocol.oidc.OIDCLoginProtocolFactory] (main) Deprecated
switch ‘legacy-logout-redirect-uri’ is enabled. Please try to disable
it and update your clients to use OpenID Connect compliant way for RP-
initiated logout.
2025-09-02 05:25:34,914 INFO
[org.keycloak.quarkus.runtime.hostname.DefaultHostnameProvider] (main)
Hostname settings: Base URL: , Hostname: localhost:8081, Strict
HTTPS: false, Path: , Strict BackChannel: true, Admin URL:
, Admin: , Port: -1, Proxied: true
2025-09-02 05:25:39,016 WARN [io.quarkus.agroal.runtime.DataSources]
(main) Datasource enables XA but transaction recovery is not
enabled. Please enable transaction recovery by setting
quarkus.transaction-manager.enable-recovery=true, otherwise data may be
lost if the application is terminated abruptly
2025-09-02 05:25:40,966 WARN
[io.quarkus.vertx.http.runtime.VertxHttpRecorder] (main) The X-
Forwarded-* and Forwarded headers will be considered when determining
the proxy address. This configuration can cause a security issue as
clients can forge requests and send a forwarded header that is not
overwritten by the proxy. Please consider use one of these headers just
to forward the proxy address in requests.
2025-09-02 05:25:41,016 INFO
[org.keycloak.connections.infinispan.DefaultInfinispanConnectionProvide
rFactory] (main) Node name: node_668674, Site name: null2025-09-02 05:25:41,471 INFO
[org.keycloak.broker.provider.AbstractIdentityProviderMapper] (main)
Registering class
org.keycloak.broker.provider.mappersync.ConfigSyncEventListener
2025-09-02 05:25:41,783 INFO
[org.keycloak.exportimport.dir.DirImportProvider] (main) Importing from
directory /keycloak-files/realm-config
2025-09-02 05:25:42,757 INFO [org.keycloak.services] (main) KC-
SERVICES0030: Full model import requested. Strategy: OVERWRITE_EXISTING
2025-09-02 05:25:43,540 INFO
[org.keycloak.exportimport.util.ImportUtils] (main) Realm ‘main’
already exists. Removing it before import
2025-09-02 05:25:50,619 WARN
[org.keycloak.models.utils.RepresentationToModel] (main) Referenced
client scope ‘acr’ doesn’t exist. Ignoring
2025-09-02 05:25:51,970 INFO
[org.keycloak.exportimport.util.ImportUtils] (main) Realm ‘main’
imported
2025-09-02 05:25:52,238 INFO [org.keycloak.services] (main) KC-
SERVICES0032: Import finished successfully
2025-09-02 05:25:52,352 INFO [io.quarkus] (main) Keycloak 24.0.3 on
JVM (powered by Quarkus 3.8.3) started in 22.626s. Listening on:
http://0.0.0.0:8081
2025-09-02 05:25:52,353 INFO [io.quarkus] (main) Profile dev
activated.
2025-09-02 05:25:52,353 INFO [io.quarkus] (main) Installed features:
[agroal, cdi, hibernate-orm, jdbc-postgresql, keycloak, logging-gelf,
micrometer, narayana-jta, reactive-routes, resteasy-reactive, resteasy-
reactive-jackson, smallrye-context-propagation, smallrye-health, vertx]
2025-09-02 05:25:52,413 WARN
[org.keycloak.quarkus.runtime.KeycloakMain] (main) Running the server
in development mode. DO NOT use this configuration in production.
Gateway Response Logs
curl -s -o /dev/null -w %{http_code} hhttp://localhost:8080/openmrs/spa
# Returns 301 redirect indicating proper routing
Keycloak Health Check
curl -s -o /dev/null -w %{http_code} hhttp://localhost:8081/realms/
master
# Returns 200, confirming realm is accessible
The OpenMRS SSO distribution system has fundamental configuration issues that prevent
optimal operation:
1 Core functionality works: Authentication flow is functional and users are created
2 System accessible: SPA can be accessed at hhttp://localhost:8080/openmrs/
spa
3 Configuration issues: Volume mounting and initialization timing need refinement
4 Primary problem: The main issue described in the beginning - when accessing
hhttp://localhost:80/openmrs/spa, the system fails to properly authenticate users
through Keycloak SSO due to configuration problems preventing proper realm file import
during startup
The system meets basic requirements for authentication with Keycloak SSO, but the volume
mounting configuration should be fixed to ensure proper realm file import during startup and
consistent initialization. Maybe there is something else I might be missing?The system meets basic requirements for authentication with Keycloak SSO, but the volume
mounting configuration should be fixed to ensure proper realm file import during startup and
consistent initialization. Maybe there is something else I might be missing?
