Hello oVirt developers,
My name is Eden, I am a Senior Systems Administrator at Semtech managing oVirt 4.5.x infrastructure across multiple sites. I am writing to the community with two related questions regarding Kerberos authentication,
and to share a bug we have found and a proposed fix.
1. IS KERBEROS AUTHENTICATION POSSIBLE WITHOUT APACHE OR KEYCLOAK?
All existing documentation for Kerberos SSO on oVirt (both the AAA-LDAP extension path and the Red Hat Virtualization Administration Guide) requires Apache with mod_auth_gssapi as an intermediary to perform SPNEGO
negotiation and pass the authenticated principal to the engine via X-Remote-User headers.
We would like to understand whether there is any supported or planned path to perform Kerberos/GSSAPI authentication directly within the oVirt engine (WildFly/JBoss), without relying on either:
- Apache + mod_auth_gssapi + ovirt-engine-extension-aaa-misc (legacy path)
- Keycloak with Kerberos User Federation (4.5.1+ path)
Specifically, the AAA-LDAP extension already supports GSSAPI binds to LDAP via the UnboundID SDK (pool.default.auth.type = gssapi). Could the engine's own SSO negotiate endpoint be extended to handle SPNEGO directly
via the JAAS/GSS-API stack running inside WildFly, eliminating the Apache dependency entirely?
We understand this may not be a currently supported configuration. If so, we would appreciate confirmation so we can plan accordingly.
2. JAVA 21 / JPMS BUG: GSSAPI LDAP BIND FAILURE IN UNBOUNDID SDK ON WILDFLY
While working on Kerberos integration for our oVirt 4.5.x environment running on CentOS Stream 10 with OpenJDK 21, we identified a critical bug that prevents GSSAPI LDAP binds from working when the AAA-LDAP extension
runs inside WildFly.
Root cause: WildFly's PicketBox security framework replaces Java's standard JAAS Configuration (sun.security.provider.ConfigFile) with its own implementation via Configuration.setConfiguration(). PicketBox's Configuration
cannot load com.sun.security.auth.module.Krb5LoginModule from the jdk.security.auth JPMS module, because PicketBox's JBoss module does not declare a dependency on jdk.security.auth. The UnboundID SDK's GSSAPIBindRequest.process() method calls Configuration.getConfiguration().refresh()
and then uses the two-argument LoginContext constructor, which internally calls Configuration.getConfiguration() again — both of which return PicketBox's broken implementation.
The result is: LoginException("No LoginModules configured for <jaasClientName>")
We verified that the standard ConfigFile implementation correctly parses the JAAS config and finds Krb5LoginModule when invoked outside of WildFly on the same JVM.
Proposed fix: Modify GSSAPIBindRequest.process() to use the four-argument LoginContext constructor with an explicit Configuration object created via Configuration.getInstance("JavaLoginConfig", new URIParameter(configURI)).
This completely bypasses the global Configuration.getConfiguration() call and uses the standard Java JAAS file parser directly. The fallback else branch preserves the original two-argument constructor behavior for non-WildFly environments.
We have a full technical write-up with bytecode evidence, the exact proposed patch, and a list of alternative approaches we tried and eliminated. We are happy to share the complete document, submit a pull request
to ovirt-engine-extension-aaa-ldap, or file a GitHub issue — whichever is preferred.
This also affects the UnboundID LDAP SDK upstream (Ping Identity), and we plan to report it there as well.
Affected versions:
- oVirt Engine 4.5.x on CentOS Stream 10
- UnboundID LDAP SDK 7.0.3 (bundled with ovirt-engine-extension-aaa-ldap 1.5.0)
- OpenJDK 21.0.6 (jdk-21.0.6+7-LTS)
- WildFly 26.x with PicketBox legacy security subsystem
Thank you for your time. We are happy to contribute testing, patches, or further analysis.
Best regards,
Eden
Senior Systems Administrator, Semtech
Eden Martinez :: Senior Staff Engineer, Linux Admin
![]()
SEMTECH CORPORATION
IT Helpdesk
+1
(855) 271 6352 ::
Office
+52 (449) 918 2823
Av. Monte Blanco 612, CP 20115, Aguascalientes, Ags.
www.semtech.com
:: Subscribe to our Newsletter
To view our privacy policy, including the types of personal information we collect, process and share, and the rights and options you have in this respect, see www.semtech.com/legal