Проблема с загрузкой классов LoginModules в домене безопасности wildfly

У меня странное поведение со следующим доменом безопасности:

                <security-domain name="Login-JBoss">
                <authentication>
                    <login-module code="com.agfa.orbis.security.auth.OrbisServerLoginModule" flag="requisite" module="com.agfa.orbis.security">
                        <module-option name="datasource" value="java:/OracleDS"/>
                    </login-module>
                    <login-module code="org.keycloak.adapters.jaas.BearerTokenLoginModule" flag="sufficient" module="org.keycloak.keycloak-adapter-core">
                        <module-option name="keycloak-config-file" value="${jboss.server.config.dir}/keycloak.json"/>
                    </login-module>
                    <login-module code="com.agfa.orbis.security.auth.OrbisLdapLoginModule" flag="sufficient" module="com.agfa.orbis.security">
                        <module-option name="try_first_pass" value="true"/>
                        <module-option name="datasource" value="java:/OracleDS"/>
                    </login-module>
                    <login-module code="com.agfa.orbis.security.auth.OrbisDatabaseLoginModule" flag="required" module="com.agfa.orbis.security">
                        <module-option name="try_first_pass" value="true"/>
                        <module-option name="datasource" value="java:/OracleDS"/>
                    </login-module>
                </authentication>
            </security-domain>

Как видите, в модуле com.agfa.orbis.security определены три модуля LoginModules, а в модуле org.keycloak.keycloak-adapter-core определен один. Когда я пытаюсь аутентифицироваться в домене безопасности, я получаю следующий вывод в своем журнале сервера (я удалил некоторые нерелевантные строки в середине, отмеченные точками):

    2017-01-12 08:31:17,495 TRACE [org.jboss.security] (default task-12) () PBOX00224: End getAppConfigurationEntry(Login-JBoss), AuthInfo: AppConfigurationEntry[]:
[0]
LoginModule Class: com.agfa.orbis.security.auth.OrbisServerLoginModule
ControlFlag: LoginModuleControlFlag: requisite
Options:
name=datasource, value=java:/OracleDS
[1]
LoginModule Class: org.keycloak.adapters.jaas.BearerTokenLoginModule
ControlFlag: LoginModuleControlFlag: sufficient
Options:
name=keycloak-config-file, value=D:\views\oas\oas-08042800\server\orbis-as-08.04.28.00.a20170104195120-DACHL\standalone\configuration/keycloak.json
[2]
LoginModule Class: com.agfa.orbis.security.auth.OrbisLdapLoginModule
ControlFlag: LoginModuleControlFlag: sufficient
Options:
name=try_first_pass, value=true
name=datasource, value=java:/OracleDS
[3]
LoginModule Class: com.agfa.orbis.security.auth.OrbisDatabaseLoginModule
ControlFlag: LoginModuleControlFlag: required
Options:
name=try_first_pass, value=true
name=datasource, value=java:/OracleDS

..........

2017-01-12 08:31:17,499 TRACE [org.jboss.security] (default task-12) () PBOX00236: Begin initialize method
2017-01-12 08:31:17,524 DEBUG [org.jboss.security] (default task-12) () PBOX00206: Login failure: javax.security.auth.login.LoginException: LoginModule-Klasse kann nicht gefunden werden: org.keycloak.adapters.jaas.BearerTokenLoginModule from [Module "deployment.orbis-framework.war:main" from Service Module Loader]
    at javax.security.auth.login.LoginContext.invoke(LoginContext.java:794)
    at javax.security.auth.login.LoginContext.access$000(LoginContext.java:195)
    at javax.security.auth.login.LoginContext$4.run(LoginContext.java:682)
    at javax.security.auth.login.LoginContext$4.run(LoginContext.java:680)
    at java.security.AccessController.doPrivileged(Native Method)
    at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:680)
    at javax.security.auth.login.LoginContext.login(LoginContext.java:587)
    at org.jboss.security.authentication.JBossCachedAuthenticationManager.defaultLogin(JBossCachedAuthenticationManager.java:406)
    at org.jboss.security.authentication.JBossCachedAuthenticationManager.proceedWithJaasLogin(JBossCachedAuthenticationManager.java:345)
    at org.jboss.security.authentication.JBossCachedAuthenticationManager.authenticate(JBossCachedAuthenticationManager.java:323)
    at org.jboss.security.authentication.JBossCachedAuthenticationManager.isValid(JBossCachedAuthenticationManager.java:146)
    at org.wildfly.extension.undertow.security.JAASIdentityManagerImpl.verifyCredential(JAASIdentityManagerImpl.java:123)
    at org.wildfly.extension.undertow.security.JAASIdentityManagerImpl.verify(JAASIdentityManagerImpl.java:94)
    at io.undertow.security.impl.BasicAuthenticationMechanism.authenticate(BasicAuthenticationMechanism.java:167)
    at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:245)
    at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:263)
    at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.access$100(SecurityContextImpl.java:231)
    at io.undertow.security.impl.SecurityContextImpl.attemptAuthentication(SecurityContextImpl.java:125)
    at io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:99)
    at io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:92)
    at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55)
    at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33)
    at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
    at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53)
    at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
    at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
    at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59)
    at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
    at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
    at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
    at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
    at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
    at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
    at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
    at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
    at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
    at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
    at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
    at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
    at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
    at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
    at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
    at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
    at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
    at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
    at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
    at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
    at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
    at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
    at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
    at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
    at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:805)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
    at java.lang.Thread.run(Thread.java:745)

2017-01-12 08:31:17,524 TRACE [org.jboss.security] (default task-12) () PBOX00201: End isValid, result = false

Я удивлен, обнаружив «ClassNotFoundException» только в режиме отладки, но это вовсе не мой главный вопрос. Проблема, которая меня удивляет, заключается в том, что он отлично работает, когда я определяю модуль org.keycloak.keycloak-adapter-core как глобальный модуль (это также указывает на то, что модули установлены правильно). Во время тестирования я также обнаружил, что получаю ту же ошибку, но для класса com.agfa.orbis.security.auth.OrbisServerLoginModule, когда я удаляю последние два модуля входа в систему из моей конфигурации. Так вроде бы и есть: только классы последнего определенного модуля являются частью пути к классам, но это всего лишь предположение.

Вы хоть представляете, что здесь происходит? Любая помощь приветствуется!


security wildfly-10
person Christian Fröhlich    schedule 12.01.2017    source источник

Ответы (2)


arrow_upward
1
arrow_downward

Я получил ту же ошибку при попытке защитить какой-либо веб-сервис с помощью Keycloak.

Решение, которое я нашел, состояло в том, чтобы добавить зависимость от модуля Keycloak (а именно модуля «keycloak-adapter-core») в сгенерированном MANIFEST.MF.

Если вы используете Maven для создания своего проекта, вы можете добиться этого, настроив «maven-jar-plugin» («архив» является соответствующей частью).

    <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-jar-plugin</artifactId>
        <version>3.0.2</version>
        <configuration>
            <archive>
                <manifestEntries>
                    <Dependencies>org.keycloak.keycloak-adapter-core</Dependencies>
                </manifestEntries>
            </archive>
        </configuration>
    </plugin>

Ваш сгенерированный MANIFEST.MF должен иметь эту запись:

Dependencies: org.keycloak.keycloak-adapter-core

Возможно, та же ошибка происходит с вашей конфигурацией Orbis. Вы можете добавить обе зависимости через запятую.

Для справки:

https://docs.jboss.org/author/display/MODULES/Manifest+module+information

person Alejandro Gianetti    schedule 26.01.2017
comment
Ваше предложение работает, когда все развертывания находятся в вашей ответственности, и вы можете легко добавить зависимость манифеста. У нас есть много развертываний от разных команд, которые используют описанный домен безопасности, поэтому каждая команда должна добавлять зависимость к каждому WAR или EAR. Мы нашли другое решение для исправления ошибки (см. ниже). - person Christian Fröhlich; 28.01.2017

arrow_upward
1
arrow_downward

Мы решили эту ошибку, добавив зависимость «org.keycloak.keycloak-adapter-core» в module.xml «com.agfa.orbis.security». Этот модуль управляется нами, поэтому его было легко внедрить. Я не могу объяснить, почему это работает, но это работает :-/

person Christian Fröhlich    schedule 27.01.2017