Classloading Ausgabe von LoginModules in einer Wildfly Sicherheitsdomäne

ich ein seltsames Verhalten mit dem folgenden Sicherheitsdomäne haben:Classloading Ausgabe von LoginModules in einer Wildfly Sicherheitsdomäne

   <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>

Wie Sie sehen, gibt es drei LoginModules im Modul definiert com.agfa.orbis.security und eine in dem Modul definiert ist org.keycloak.keycloak-adapter-core . Wenn ich versuche, gegen die Sicherheitsdomäne zu authentifizieren ich die folgende Ausgabe in meinem Server Log bekam (ich löschte einige nicht relevanten Zeilen in der Mitte mit den Punkten markiert):

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

Ich bin überrascht, dass die „ClassNotFoundException zu finden "Nur im Debug-Modus, aber das ist nicht meine Hauptfrage. Das Problem, das ich überrascht, ist, dass es funktioniert, wenn ich das Modul org.keycloak.keycloak-adapter-core als globales Modul (das zeigt auch, dass die Module korrekt installiert sind) definieren. Während des Tests erkenne ich auch, dass ich den gleichen Fehler bekomme, aber für die Klasse com.agfa.orbis.security.auth.OrbisServerLoginModule, wenn ich die letzten zwei LoginModule aus meiner Konfiguration lösche. So scheint es zu sein: Nur die Klassen des zuletzt definierten Moduls sind Teil des Klassenpfads, aber das ist nur eine Annahme.

Haben Sie eine Idee, was hier schief läuft? Jede Hilfe ist willkommen!

Quelle

2017-01-12 Christian Fröhlich

Ich habe den gleichen Fehler beim Versuch, einige Web-Service mit Keycloak zu sichern.

Die Lösung fand ich war die Abhängigkeit von der Keycloak Modul (nämlich das „keycloak-Adapter-core“ Modul) in dem erzeugten MANIFEST.MF hinzuzufügen.

Wenn Sie Maven verwenden, um Ihr Projekt zu erstellen, können Sie dies erreichen, indem die „maven-jar-plugin“ Konfiguration („Archiv“ ist der relevante Teil).

<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>

Ihre erzeugte MANIFEST.MF sollte diesen Eintrag haben:

Dependencies: org.keycloak.keycloak-adapter-core

Vielleicht ist der gleiche Fehler mit Ihrem Orbis Config geschieht. Sie können beide Abhängigkeiten getrennt durch ein Komma hinzufügen.

als Referenz:

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

Quelle

2017-01-26 13:00:43

Ihr Vorschlag arbeitet, wenn alle Einsätze in Ihrer Verantwortung, und Sie können leicht das Manifest Abhängigkeit hinzufügen. Wir haben viele Implementierungen von verschiedenen Teams, die die beschriebene Sicherheitsdomäne verwenden, sodass jedes Team die Abhängigkeit zu jeder WAR oder EAR hinzufügen muss. Wir haben eine andere Lösung gefunden, um den Fehler zu beheben (siehe unten). –

Wir lösten den Fehler durch eine Abhängigkeit von der auf die module.xml von ‚com.agfa.orbis 'org.keycloak.keycloak-Adapter-core' hinzugefügt wird. Sicherheit'. Dieses Modul wird von uns verwaltet, so dass es einfach zu implementieren war. Ich kann nicht erklären, warum es funktioniert, aber es funktioniert: -/

Quelle

2017-01-27 21:32:45

Classloading Ausgabe von LoginModules in einer Wildfly Sicherheitsdomäne

Antwort

Verwandte Themen