Devel

Download

devel@ovirt.org

March 2026

2 participants
1 discussions

[RFC] Kerberos/GSSAPI authentication on oVirt 4.5.x without Apache — feasibility question + Java 21 JPMS bug in UnboundID SDK
by Eden Martinez 04 Mar '26

04 Mar '26

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 [cid:image001.png@01DCAB0A.ED1B6350] SEMTECH CORPORATION IT Helpdesk +1 (855) 271 6352 :: Office +52 (449) 918 2823 Av. Monte Blanco 612, CP 20115, Aguascalientes, Ags. [cid:image002.gif@01DCAB0A.ED1B6350]<https://www.linkedin.com/company/semtech> [cid:image003.gif@01DCAB0A.ED1B6350]<https://twitter.com/SemtechCorp> [cid:image004.gif@01DCAB0A.ED1B6350]<https://blog.semtech.com/> www.semtech.com<https://www.semtech.com/> :: Subscribe to our Newsletter<https://www.semtech.com/subscribe> 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.

2 1