[JBoss JIRA] (WFLY-7706) LdapRealm - referral mode: direct verification + THROW mode
by Jan Kalina (JIRA)
Jan Kalina created WFLY-7706:
--------------------------------
Summary: LdapRealm - referral mode: direct verification + THROW mode
Key: WFLY-7706
URL: https://issues.jboss.org/browse/WFLY-7706
Project: WildFly
Issue Type: Feature Request
Components: Security
Reporter: Jan Kalina
Assignee: Jan Kalina
Priority: Blocker
*1) Log in as referral user is still not possible.*
Currently referral user can be found by ldap realm, but his password cannot be verified => log in is still not possible.
There are two possible ways how to authenticate user in ldap realm:
using direct verification - in this case after obtaining referral user, this referral user is used in LDAP bindRequest against original LDAP server (not referenced LDAP server) which results to invalid credentials bindResponse
not using direct verification - in this case after obtaining referral user, this user is used as part of baseObject scope LDAP searchRequest for password attribute against original LDAP server (not referenced LDAP server) which results to noSuchObject searchResDone.
Comment [1] says that you are able to log in as user of referred server. Can you please share your configuration? Since there is no related documentation, maybe I do something wrong in using/not using of direct verification.
*2) Elytron does not handle THROW referral mode*
In case when dir-context uses THROW referral-mode then com.sun.jndi.ldap.LdapReferralException is not caught in Elytron (which is LDAP client) and is thrown to integration tier which also does not handle it, e.g. in case when ldap-realm is used for authentication to application, then it results to status code 500 returned to the application.
[1] https://issues.jboss.org/browse/WFLY-7322?focusedCommentId=13307815&page=...
( Requested in https://issues.jboss.org/browse/JBEAP-6450?focusedCommentId=13323387#comm... )
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 5 months
[JBoss JIRA] (WFLY-7705) LdapRealm - referral mode: direct verification + THROW mode
by Jan Kalina (JIRA)
Jan Kalina created WFLY-7705:
--------------------------------
Summary: LdapRealm - referral mode: direct verification + THROW mode
Key: WFLY-7705
URL: https://issues.jboss.org/browse/WFLY-7705
Project: WildFly
Issue Type: Feature Request
Components: Security
Reporter: Jan Kalina
Assignee: Jan Kalina
Priority: Blocker
1) Log in as referral user is still not possible.
Currently referral user can be found by ldap realm, but his password cannot be verified => log in is still not possible.
There are two possible ways how to authenticate user in ldap realm:
using direct verification - in this case after obtaining referral user, this referral user is used in LDAP bindRequest against original LDAP server (not referenced LDAP server) which results to invalid credentials bindResponse
not using direct verification - in this case after obtaining referral user, this user is used as part of baseObject scope LDAP searchRequest for password attribute against original LDAP server (not referenced LDAP server) which results to noSuchObject searchResDone.
Comment [1] says that you are able to log in as user of referred server. Can you please share your configuration? Since there is no related documentation, maybe I do something wrong in using/not using of direct verification.
2) Elytron does not handle THROW referral mode
In case when dir-context uses THROW referral-mode then com.sun.jndi.ldap.LdapReferralException is not caught in Elytron (which is LDAP client) and is thrown to integration tier which also does not handle it, e.g. in case when ldap-realm is used for authentication to application, then it results to status code 500 returned to the application.
[1] https://issues.jboss.org/browse/WFLY-7322?focusedCommentId=13307815&page=...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 5 months
[JBoss JIRA] (WFLY-7705) LdapRealm - referral mode: direct verification + THROW mode
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFLY-7705?page=com.atlassian.jira.plugin.... ]
Jan Kalina updated WFLY-7705:
-----------------------------
Description:
*1) Log in as referral user is still not possible.*
Currently referral user can be found by ldap realm, but his password cannot be verified => log in is still not possible.
There are two possible ways how to authenticate user in ldap realm:
using direct verification - in this case after obtaining referral user, this referral user is used in LDAP bindRequest against original LDAP server (not referenced LDAP server) which results to invalid credentials bindResponse
not using direct verification - in this case after obtaining referral user, this user is used as part of baseObject scope LDAP searchRequest for password attribute against original LDAP server (not referenced LDAP server) which results to noSuchObject searchResDone.
Comment [1] says that you are able to log in as user of referred server. Can you please share your configuration? Since there is no related documentation, maybe I do something wrong in using/not using of direct verification.
*2) Elytron does not handle THROW referral mode*
In case when dir-context uses THROW referral-mode then com.sun.jndi.ldap.LdapReferralException is not caught in Elytron (which is LDAP client) and is thrown to integration tier which also does not handle it, e.g. in case when ldap-realm is used for authentication to application, then it results to status code 500 returned to the application.
[1] https://issues.jboss.org/browse/WFLY-7322?focusedCommentId=13307815&page=...
( Requested in https://issues.jboss.org/browse/JBEAP-6450?focusedCommentId=13323387#comm... )
was:
1) Log in as referral user is still not possible.
Currently referral user can be found by ldap realm, but his password cannot be verified => log in is still not possible.
There are two possible ways how to authenticate user in ldap realm:
using direct verification - in this case after obtaining referral user, this referral user is used in LDAP bindRequest against original LDAP server (not referenced LDAP server) which results to invalid credentials bindResponse
not using direct verification - in this case after obtaining referral user, this user is used as part of baseObject scope LDAP searchRequest for password attribute against original LDAP server (not referenced LDAP server) which results to noSuchObject searchResDone.
Comment [1] says that you are able to log in as user of referred server. Can you please share your configuration? Since there is no related documentation, maybe I do something wrong in using/not using of direct verification.
2) Elytron does not handle THROW referral mode
In case when dir-context uses THROW referral-mode then com.sun.jndi.ldap.LdapReferralException is not caught in Elytron (which is LDAP client) and is thrown to integration tier which also does not handle it, e.g. in case when ldap-realm is used for authentication to application, then it results to status code 500 returned to the application.
[1] https://issues.jboss.org/browse/WFLY-7322?focusedCommentId=13307815&page=...
> LdapRealm - referral mode: direct verification + THROW mode
> ------------------------------------------------------------
>
> Key: WFLY-7705
> URL: https://issues.jboss.org/browse/WFLY-7705
> Project: WildFly
> Issue Type: Feature Request
> Components: Security
> Reporter: Jan Kalina
> Assignee: Jan Kalina
> Priority: Blocker
>
> *1) Log in as referral user is still not possible.*
> Currently referral user can be found by ldap realm, but his password cannot be verified => log in is still not possible.
> There are two possible ways how to authenticate user in ldap realm:
> using direct verification - in this case after obtaining referral user, this referral user is used in LDAP bindRequest against original LDAP server (not referenced LDAP server) which results to invalid credentials bindResponse
> not using direct verification - in this case after obtaining referral user, this user is used as part of baseObject scope LDAP searchRequest for password attribute against original LDAP server (not referenced LDAP server) which results to noSuchObject searchResDone.
> Comment [1] says that you are able to log in as user of referred server. Can you please share your configuration? Since there is no related documentation, maybe I do something wrong in using/not using of direct verification.
> *2) Elytron does not handle THROW referral mode*
> In case when dir-context uses THROW referral-mode then com.sun.jndi.ldap.LdapReferralException is not caught in Elytron (which is LDAP client) and is thrown to integration tier which also does not handle it, e.g. in case when ldap-realm is used for authentication to application, then it results to status code 500 returned to the application.
> [1] https://issues.jboss.org/browse/WFLY-7322?focusedCommentId=13307815&page=...
> ( Requested in https://issues.jboss.org/browse/JBEAP-6450?focusedCommentId=13323387#comm... )
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 5 months
[JBoss JIRA] (WFLY-7704) JVM segfault: mod_cluster subsystem cannot handle wildfly-openssl integration
by Michal Karm Babacek (JIRA)
[ https://issues.jboss.org/browse/WFLY-7704?page=com.atlassian.jira.plugin.... ]
Michal Karm Babacek reopened WFLY-7704:
---------------------------------------
> JVM segfault: mod_cluster subsystem cannot handle wildfly-openssl integration
> -----------------------------------------------------------------------------
>
> Key: WFLY-7704
> URL: https://issues.jboss.org/browse/WFLY-7704
> Project: WildFly
> Issue Type: Bug
> Components: mod_cluster
> Affects Versions: 10.1.0.Final
> Reporter: Michal Karm Babacek
> Assignee: Stuart Douglas
> Priority: Critical
>
> h3. Preface
> mod_cluster subsystem doesn't use Security Realms, unfortunately, so one must replicate SSL configuration both in security realms and in mod_cluster subsystem.
> Apparently, there is a confusion about setting protocol and cipher suite in integration between mod_cluster subsystem and wildfly-openssl:
> {noformat}
> at org.wildfly.openssl.OpenSSLEngine.setEnabledProtocols(OpenSSLEngine.java:754)
> at org.wildfly.openssl.OpenSSLSocket.setEnabledCipherSuites(OpenSSLSocket.java:204)
> at org.jboss.modcluster.mcmp.impl.JSSESocketFactory.initSocket(JSSESocketFactory.java:384)
> at org.jboss.modcluster.mcmp.impl.JSSESocketFactory.createSocket(JSSESocketFactory.java:124)
> {noformat}
> h3. Configuration
> {code}
> <security-realm name="JBossTestServer">
> <server-identities>
> <ssl protocol="openssl.TLS">
> <engine enabled-cipher-suites="TLS_RSA_WITH_AES_128_GCM_SHA256"/>
> <keystore provider="JKS" path="/opt/noe-tests/resources/ssl/proper/server-cert-key.jks" keystore-password="tomcat" alias="javaserver"/>
> </ssl>
> </server-identities>
> <authentication>
> <truststore path="/opt/noe-tests/resources/ssl/proper/ca-cert.jks" keystore-password="tomcat"/>
> </authentication>
> </security-realm>
> <subsystem xmlns="urn:jboss:domain:modcluster:2.0">
> <mod-cluster-config advertise-socket="modcluster" connector="https">
> <dynamic-load-provider>
> <load-metric type="cpu"/>
> </dynamic-load-provider>
> <ssl key-alias="javaclient" password="tomcat" certificate-key-file="/opt/noe-tests/resources/ssl/proper/client-cert-key.jks" cipher-suite="TLS_RSA_WITH_AES_128_GCM_SHA256" protocol="openssl.TLS" ca-certificate-file="/opt/noe-tests/resources/ssl/proper/ca-cert.jks"/>
> </mod-cluster-config>
> </subsystem>
> [org.wildfly.openssl.SSL] OpenSSL Version OpenSSL 1.0.2h-fips 3 May 2016
> {code}
> h3. JVM segfault
> Java Stackstrace on MCMP handler registration: [OpenSSLEngine.java:L754|https://github.com/wildfly/wildfly-openssl/blob/1...]
> {noformat}
> 12:01:02,249 ERROR [org.jboss.mod_cluster.undertow] (UndertowEventHandlerAdapter - 1) Unsupported protocol TLS_RSA_WITH_AES_128_GCM_SHA256: java.lang.IllegalArgumentException: Unsupported protocol TLS_RSA_WITH_AES_128_GCM_SHA256
> at org.wildfly.openssl.OpenSSLEngine.setEnabledProtocols(OpenSSLEngine.java:754)
> at org.wildfly.openssl.OpenSSLSocket.setEnabledCipherSuites(OpenSSLSocket.java:204)
> at org.jboss.modcluster.mcmp.impl.JSSESocketFactory.initSocket(JSSESocketFactory.java:384)
> at org.jboss.modcluster.mcmp.impl.JSSESocketFactory.createSocket(JSSESocketFactory.java:124)
> at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler$Proxy.getConnection(DefaultMCMPHandler.java:850)
> at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler$Proxy.getConnectionWriter(DefaultMCMPHandler.java:886)
> at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.sendRequest(DefaultMCMPHandler.java:514)
> at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.sendRequest(DefaultMCMPHandler.java:605)
> at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.status(DefaultMCMPHandler.java:387)
> at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.status(DefaultMCMPHandler.java:365)
> at org.jboss.modcluster.ModClusterService.status(ModClusterService.java:454)
> at org.wildfly.mod_cluster.undertow.UndertowEventHandlerAdapter.run(UndertowEventHandlerAdapter.java:179)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
> 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)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> {noformat}causes JVM segfault: {noformat}#
> # A fatal error has been detected by the Java Runtime Environment:
> #
> # SIGSEGV (0xb) at pc=0x00007fd40e7798c5, pid=29489, tid=0x00007fd44f7f7700
> #{noformat}
> Java and Native stacktrace: for a call from Java [byte\[\] getSessionId0(long ssl)|https://github.com/wildfly/wildfly-openssl/blob/1.0.0.Alpha4/java/sr...] to C [getting session from underlying OpenSSL integration fails|https://github.com/wildfly/wildfly-openssl/blob/1.0.0.Alpha4/libwfs...: [0x00007fd44f6f7000,0x00007fd44f7f8000], sp=0x00007fd44f7f6358, free space=1020k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> C [libssl.so+0x478c5] SSL_SESSION_get_id+0x5
> C [libwfssl.so+0x4a0b] Java_org_wildfly_openssl_SSLImpl_getSessionId0+0x6b
> j org.wildfly.openssl.SSLImpl.getSessionId0(J)[B+0
> j org.wildfly.openssl.SSLImpl.getSessionId(J)[B+1
> j org.wildfly.openssl.OpenSSLEngine.shutdown()V+42
> j org.wildfly.openssl.OpenSSLEngine.finalize()V+5
> J 1218 C1 java.lang.ref.Finalizer.runFinalizer(Lsun/misc/JavaLangAccess;)V (62 bytes) @ 0x00007fd4593dbf84 [0x00007fd4593dba00+0x584]
> J 1217 C1 java.lang.ref.Finalizer.access$100(Ljava/lang/ref/Finalizer;Lsun/misc/JavaLangAccess;)V (6 bytes) @ 0x00007fd4593db69c [0x00007fd4593db640+0x5c]
> j java.lang.ref.Finalizer$FinalizerThread.run()V+45
> v ~StubRoutines::call_stub
> V [libjvm.so+0x657fbb]
> V [libjvm.so+0x6593b7]
> V [libjvm.so+0x659877]
> V [libjvm.so+0x6a9371]
> V [libjvm.so+0x9de335]
> V [libjvm.so+0x9de590]
> V [libjvm.so+0x8a18b2]
> C [libpthread.so.0+0x7aa1]
> Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
> j org.wildfly.openssl.SSLImpl.getSessionId0(J)[B+0
> j org.wildfly.openssl.SSLImpl.getSessionId(J)[B+1
> j org.wildfly.openssl.OpenSSLEngine.shutdown()V+42
> j org.wildfly.openssl.OpenSSLEngine.finalize()V+5
> J 1218 C1 java.lang.ref.Finalizer.runFinalizer(Lsun/misc/JavaLangAccess;)V (62 bytes) @ 0x00007fd4593dbf84 [0x00007fd4593dba00+0x584]
> J 1217 C1 java.lang.ref.Finalizer.access$100(Ljava/lang/ref/Finalizer;Lsun/misc/JavaLangAccess;)V (6 bytes) @ 0x00007fd4593db69c [0x00007fd4593db640+0x5c]
> j java.lang.ref.Finalizer$FinalizerThread.run()V+45
> v ~StubRoutines::call_stub{noformat}
> h3. OpenSSL 1.0.2h
> This is the declaration of the called [SSL_SESSION_get_id|https://github.com/openssl/openssl/blob/OpenSSL_1_0_2h...] and this is the definition in [ssl_sess.c|https://github.com/openssl/openssl/blob/OpenSSL_1_0_2h/ssl/ssl...]
> h3. Conclusion
> IMHO it wouldn't do any harm to check whether {{session}} ain't NULL before passing it on down to OpenSSL, but it is only the aftermath, not the original cause I suppose. It might be worth checking whether the bug is actually not simply in the mod_cluster java part, in calling {{org.wildfly.openssl.OpenSSLEngine}} with confused protocols/cipher suites.
> Cheers
> -K-
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 5 months
[JBoss JIRA] (WFLY-7704) JVM segfault: mod_cluster subsystem cannot handle wildfly-openssl integration
by Michal Karm Babacek (JIRA)
[ https://issues.jboss.org/browse/WFLY-7704?page=com.atlassian.jira.plugin.... ]
Michal Karm Babacek moved MODCLUSTER-554 to WFLY-7704:
------------------------------------------------------
Project: WildFly (was: mod_cluster)
Key: WFLY-7704 (was: MODCLUSTER-554)
Component/s: mod_cluster
(was: Core & Container Integration (Java))
Affects Version/s: 10.1.0.Final
(was: 1.3.5.Final)
> JVM segfault: mod_cluster subsystem cannot handle wildfly-openssl integration
> -----------------------------------------------------------------------------
>
> Key: WFLY-7704
> URL: https://issues.jboss.org/browse/WFLY-7704
> Project: WildFly
> Issue Type: Bug
> Components: mod_cluster
> Affects Versions: 10.1.0.Final
> Reporter: Michal Karm Babacek
> Assignee: Stuart Douglas
> Priority: Critical
>
> h3. Preface
> mod_cluster subsystem doesn't use Security Realms, unfortunately, so one must replicate SSL configuration both in security realms and in mod_cluster subsystem.
> Apparently, there is a confusion about setting protocol and cipher suite in integration between mod_cluster subsystem and wildfly-openssl:
> {noformat}
> at org.wildfly.openssl.OpenSSLEngine.setEnabledProtocols(OpenSSLEngine.java:754)
> at org.wildfly.openssl.OpenSSLSocket.setEnabledCipherSuites(OpenSSLSocket.java:204)
> at org.jboss.modcluster.mcmp.impl.JSSESocketFactory.initSocket(JSSESocketFactory.java:384)
> at org.jboss.modcluster.mcmp.impl.JSSESocketFactory.createSocket(JSSESocketFactory.java:124)
> {noformat}
> h3. Configuration
> {code}
> <security-realm name="JBossTestServer">
> <server-identities>
> <ssl protocol="openssl.TLS">
> <engine enabled-cipher-suites="TLS_RSA_WITH_AES_128_GCM_SHA256"/>
> <keystore provider="JKS" path="/opt/noe-tests/resources/ssl/proper/server-cert-key.jks" keystore-password="tomcat" alias="javaserver"/>
> </ssl>
> </server-identities>
> <authentication>
> <truststore path="/opt/noe-tests/resources/ssl/proper/ca-cert.jks" keystore-password="tomcat"/>
> </authentication>
> </security-realm>
> <subsystem xmlns="urn:jboss:domain:modcluster:2.0">
> <mod-cluster-config advertise-socket="modcluster" connector="https">
> <dynamic-load-provider>
> <load-metric type="cpu"/>
> </dynamic-load-provider>
> <ssl key-alias="javaclient" password="tomcat" certificate-key-file="/opt/noe-tests/resources/ssl/proper/client-cert-key.jks" cipher-suite="TLS_RSA_WITH_AES_128_GCM_SHA256" protocol="openssl.TLS" ca-certificate-file="/opt/noe-tests/resources/ssl/proper/ca-cert.jks"/>
> </mod-cluster-config>
> </subsystem>
> [org.wildfly.openssl.SSL] OpenSSL Version OpenSSL 1.0.2h-fips 3 May 2016
> {code}
> h3. JVM segfault
> Java Stackstrace on MCMP handler registration: [OpenSSLEngine.java:L754|https://github.com/wildfly/wildfly-openssl/blob/1...]
> {noformat}
> 12:01:02,249 ERROR [org.jboss.mod_cluster.undertow] (UndertowEventHandlerAdapter - 1) Unsupported protocol TLS_RSA_WITH_AES_128_GCM_SHA256: java.lang.IllegalArgumentException: Unsupported protocol TLS_RSA_WITH_AES_128_GCM_SHA256
> at org.wildfly.openssl.OpenSSLEngine.setEnabledProtocols(OpenSSLEngine.java:754)
> at org.wildfly.openssl.OpenSSLSocket.setEnabledCipherSuites(OpenSSLSocket.java:204)
> at org.jboss.modcluster.mcmp.impl.JSSESocketFactory.initSocket(JSSESocketFactory.java:384)
> at org.jboss.modcluster.mcmp.impl.JSSESocketFactory.createSocket(JSSESocketFactory.java:124)
> at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler$Proxy.getConnection(DefaultMCMPHandler.java:850)
> at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler$Proxy.getConnectionWriter(DefaultMCMPHandler.java:886)
> at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.sendRequest(DefaultMCMPHandler.java:514)
> at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.sendRequest(DefaultMCMPHandler.java:605)
> at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.status(DefaultMCMPHandler.java:387)
> at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.status(DefaultMCMPHandler.java:365)
> at org.jboss.modcluster.ModClusterService.status(ModClusterService.java:454)
> at org.wildfly.mod_cluster.undertow.UndertowEventHandlerAdapter.run(UndertowEventHandlerAdapter.java:179)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
> 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)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> {noformat}causes JVM segfault: {noformat}#
> # A fatal error has been detected by the Java Runtime Environment:
> #
> # SIGSEGV (0xb) at pc=0x00007fd40e7798c5, pid=29489, tid=0x00007fd44f7f7700
> #{noformat}
> Java and Native stacktrace: for a call from Java [byte\[\] getSessionId0(long ssl)|https://github.com/wildfly/wildfly-openssl/blob/1.0.0.Alpha4/java/sr...] to C [getting session from underlying OpenSSL integration fails|https://github.com/wildfly/wildfly-openssl/blob/1.0.0.Alpha4/libwfs...: [0x00007fd44f6f7000,0x00007fd44f7f8000], sp=0x00007fd44f7f6358, free space=1020k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> C [libssl.so+0x478c5] SSL_SESSION_get_id+0x5
> C [libwfssl.so+0x4a0b] Java_org_wildfly_openssl_SSLImpl_getSessionId0+0x6b
> j org.wildfly.openssl.SSLImpl.getSessionId0(J)[B+0
> j org.wildfly.openssl.SSLImpl.getSessionId(J)[B+1
> j org.wildfly.openssl.OpenSSLEngine.shutdown()V+42
> j org.wildfly.openssl.OpenSSLEngine.finalize()V+5
> J 1218 C1 java.lang.ref.Finalizer.runFinalizer(Lsun/misc/JavaLangAccess;)V (62 bytes) @ 0x00007fd4593dbf84 [0x00007fd4593dba00+0x584]
> J 1217 C1 java.lang.ref.Finalizer.access$100(Ljava/lang/ref/Finalizer;Lsun/misc/JavaLangAccess;)V (6 bytes) @ 0x00007fd4593db69c [0x00007fd4593db640+0x5c]
> j java.lang.ref.Finalizer$FinalizerThread.run()V+45
> v ~StubRoutines::call_stub
> V [libjvm.so+0x657fbb]
> V [libjvm.so+0x6593b7]
> V [libjvm.so+0x659877]
> V [libjvm.so+0x6a9371]
> V [libjvm.so+0x9de335]
> V [libjvm.so+0x9de590]
> V [libjvm.so+0x8a18b2]
> C [libpthread.so.0+0x7aa1]
> Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
> j org.wildfly.openssl.SSLImpl.getSessionId0(J)[B+0
> j org.wildfly.openssl.SSLImpl.getSessionId(J)[B+1
> j org.wildfly.openssl.OpenSSLEngine.shutdown()V+42
> j org.wildfly.openssl.OpenSSLEngine.finalize()V+5
> J 1218 C1 java.lang.ref.Finalizer.runFinalizer(Lsun/misc/JavaLangAccess;)V (62 bytes) @ 0x00007fd4593dbf84 [0x00007fd4593dba00+0x584]
> J 1217 C1 java.lang.ref.Finalizer.access$100(Ljava/lang/ref/Finalizer;Lsun/misc/JavaLangAccess;)V (6 bytes) @ 0x00007fd4593db69c [0x00007fd4593db640+0x5c]
> j java.lang.ref.Finalizer$FinalizerThread.run()V+45
> v ~StubRoutines::call_stub{noformat}
> h3. OpenSSL 1.0.2h
> This is the declaration of the called [SSL_SESSION_get_id|https://github.com/openssl/openssl/blob/OpenSSL_1_0_2h...] and this is the definition in [ssl_sess.c|https://github.com/openssl/openssl/blob/OpenSSL_1_0_2h/ssl/ssl...]
> h3. Conclusion
> IMHO it wouldn't do any harm to check whether {{session}} ain't NULL before passing it on down to OpenSSL, but it is only the aftermath, not the original cause I suppose. It might be worth checking whether the bug is actually not simply in the mod_cluster java part, in calling {{org.wildfly.openssl.OpenSSLEngine}} with confused protocols/cipher suites.
> Cheers
> -K-
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 5 months
[JBoss JIRA] (WFCORE-2061) JMX access unauthorized after RBAC enabled
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2061?page=com.atlassian.jira.plugi... ]
Darran Lofthouse resolved WFCORE-2061.
--------------------------------------
Fix Version/s: 3.0.0.Alpha14
Resolution: Rejected
Changing the identity for the IN-VM call to JMX is not currently supported.
However if you avoid the Subject.doAs entirely the call should be IN-VM anyway which means SuperUser would be granted by default.
>From WildFly 11 we are switching the security framework to WildFly Elytron where we will offer a lot more control of identity switching for calls.
> JMX access unauthorized after RBAC enabled
> ------------------------------------------
>
> Key: WFCORE-2061
> URL: https://issues.jboss.org/browse/WFCORE-2061
> Project: WildFly Core
> Issue Type: Bug
> Components: JMX, Security
> Affects Versions: 2.2.0.Final
> Reporter: Tadayoshi Sato
> Assignee: Darran Lofthouse
> Fix For: 3.0.0.Alpha14
>
> Attachments: standalone.xml, wildfly-jmx-auth.zip
>
>
> After RBAC is enabled, even a user ({{"admin"}}) with {{SuperUser}} role fails to get authorized access to JMX with the following code:
> {code:java}
> MBeanServer mBeanServer = ...
> Subject subject = new Subject();
> // Login
> new LoginContext("test-domain", subject, callbacks -> { ... }).login();
> // Access to JMX
> Subject.doAs(subject, (PrivilegedAction<Object>) () -> {
> mBeanServer.getAttribute(new ObjectName("java.lang:type=Memory"), "HeapMemoryUsage"));
> return null;
> });
> {code}
> RBAC and role-mapping are enabled in {{standalone.xml}} like this:
> {code:xml}
> <access-control provider="rbac">
> <role-mapping>
> <role name="SuperUser">
> <include>
> <user name="$local"/>
> <user name="admin"/>
> </include>
> </role>
> </role-mapping>
> </access-control>
> [...]
> <subsystem xmlns="urn:jboss:domain:security:1.2">
> <security-domains>
> [...]
> <security-domain name="test-domain" cache-type="default">
> <authentication>
> <login-module code="RealmDirect" flag="required">
> <module-option name="realm" value="ManagementRealm"/>
> </login-module>
> </authentication>
> </security-domain>
> {code}
> The code gets this error in the server log:
> {code}
> javax.management.JMRuntimeException: WFLYJMX0037: Unauthorized access
> at org.jboss.as.jmx.PluggableMBeanServerImpl.authorizeMBeanOperation(PluggableMBeanServerImpl.java:1203)
> at org.jboss.as.jmx.PluggableMBeanServerImpl.authorizeMBeanOperation(PluggableMBeanServerImpl.java:1190)
> at org.jboss.as.jmx.PluggableMBeanServerImpl.getAttribute(PluggableMBeanServerImpl.java:387)
> at com.redhat.issues.wildfly.JmxServlet.readMBeanAttribute(JmxServlet.java:87)
> at com.redhat.issues.wildfly.JmxServlet.lambda$process$0(JmxServlet.java:53)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:360)
> at com.redhat.issues.wildfly.JmxServlet.process(JmxServlet.java:52)
> at com.redhat.issues.wildfly.JmxServlet.doGet(JmxServlet.java:44)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 5 months
[JBoss JIRA] (WFCORE-2061) JMX access unauthorized after RBAC enabled
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2061?page=com.atlassian.jira.plugi... ]
Darran Lofthouse updated WFCORE-2061:
-------------------------------------
Priority: Major (was: Critical)
> JMX access unauthorized after RBAC enabled
> ------------------------------------------
>
> Key: WFCORE-2061
> URL: https://issues.jboss.org/browse/WFCORE-2061
> Project: WildFly Core
> Issue Type: Bug
> Components: JMX, Security
> Affects Versions: 2.2.0.Final
> Reporter: Tadayoshi Sato
> Assignee: Darran Lofthouse
> Attachments: standalone.xml, wildfly-jmx-auth.zip
>
>
> After RBAC is enabled, even a user ({{"admin"}}) with {{SuperUser}} role fails to get authorized access to JMX with the following code:
> {code:java}
> MBeanServer mBeanServer = ...
> Subject subject = new Subject();
> // Login
> new LoginContext("test-domain", subject, callbacks -> { ... }).login();
> // Access to JMX
> Subject.doAs(subject, (PrivilegedAction<Object>) () -> {
> mBeanServer.getAttribute(new ObjectName("java.lang:type=Memory"), "HeapMemoryUsage"));
> return null;
> });
> {code}
> RBAC and role-mapping are enabled in {{standalone.xml}} like this:
> {code:xml}
> <access-control provider="rbac">
> <role-mapping>
> <role name="SuperUser">
> <include>
> <user name="$local"/>
> <user name="admin"/>
> </include>
> </role>
> </role-mapping>
> </access-control>
> [...]
> <subsystem xmlns="urn:jboss:domain:security:1.2">
> <security-domains>
> [...]
> <security-domain name="test-domain" cache-type="default">
> <authentication>
> <login-module code="RealmDirect" flag="required">
> <module-option name="realm" value="ManagementRealm"/>
> </login-module>
> </authentication>
> </security-domain>
> {code}
> The code gets this error in the server log:
> {code}
> javax.management.JMRuntimeException: WFLYJMX0037: Unauthorized access
> at org.jboss.as.jmx.PluggableMBeanServerImpl.authorizeMBeanOperation(PluggableMBeanServerImpl.java:1203)
> at org.jboss.as.jmx.PluggableMBeanServerImpl.authorizeMBeanOperation(PluggableMBeanServerImpl.java:1190)
> at org.jboss.as.jmx.PluggableMBeanServerImpl.getAttribute(PluggableMBeanServerImpl.java:387)
> at com.redhat.issues.wildfly.JmxServlet.readMBeanAttribute(JmxServlet.java:87)
> at com.redhat.issues.wildfly.JmxServlet.lambda$process$0(JmxServlet.java:53)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:360)
> at com.redhat.issues.wildfly.JmxServlet.process(JmxServlet.java:52)
> at com.redhat.issues.wildfly.JmxServlet.doGet(JmxServlet.java:44)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 5 months
[JBoss JIRA] (WFCORE-2061) JMX access unauthorized after RBAC enabled
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2061?page=com.atlassian.jira.plugi... ]
Darran Lofthouse reassigned WFCORE-2061:
----------------------------------------
Assignee: Darran Lofthouse (was: Kabir Khan)
> JMX access unauthorized after RBAC enabled
> ------------------------------------------
>
> Key: WFCORE-2061
> URL: https://issues.jboss.org/browse/WFCORE-2061
> Project: WildFly Core
> Issue Type: Bug
> Components: JMX, Security
> Affects Versions: 2.2.0.Final
> Reporter: Tadayoshi Sato
> Assignee: Darran Lofthouse
> Priority: Critical
> Attachments: standalone.xml, wildfly-jmx-auth.zip
>
>
> After RBAC is enabled, even a user ({{"admin"}}) with {{SuperUser}} role fails to get authorized access to JMX with the following code:
> {code:java}
> MBeanServer mBeanServer = ...
> Subject subject = new Subject();
> // Login
> new LoginContext("test-domain", subject, callbacks -> { ... }).login();
> // Access to JMX
> Subject.doAs(subject, (PrivilegedAction<Object>) () -> {
> mBeanServer.getAttribute(new ObjectName("java.lang:type=Memory"), "HeapMemoryUsage"));
> return null;
> });
> {code}
> RBAC and role-mapping are enabled in {{standalone.xml}} like this:
> {code:xml}
> <access-control provider="rbac">
> <role-mapping>
> <role name="SuperUser">
> <include>
> <user name="$local"/>
> <user name="admin"/>
> </include>
> </role>
> </role-mapping>
> </access-control>
> [...]
> <subsystem xmlns="urn:jboss:domain:security:1.2">
> <security-domains>
> [...]
> <security-domain name="test-domain" cache-type="default">
> <authentication>
> <login-module code="RealmDirect" flag="required">
> <module-option name="realm" value="ManagementRealm"/>
> </login-module>
> </authentication>
> </security-domain>
> {code}
> The code gets this error in the server log:
> {code}
> javax.management.JMRuntimeException: WFLYJMX0037: Unauthorized access
> at org.jboss.as.jmx.PluggableMBeanServerImpl.authorizeMBeanOperation(PluggableMBeanServerImpl.java:1203)
> at org.jboss.as.jmx.PluggableMBeanServerImpl.authorizeMBeanOperation(PluggableMBeanServerImpl.java:1190)
> at org.jboss.as.jmx.PluggableMBeanServerImpl.getAttribute(PluggableMBeanServerImpl.java:387)
> at com.redhat.issues.wildfly.JmxServlet.readMBeanAttribute(JmxServlet.java:87)
> at com.redhat.issues.wildfly.JmxServlet.lambda$process$0(JmxServlet.java:53)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:360)
> at com.redhat.issues.wildfly.JmxServlet.process(JmxServlet.java:52)
> at com.redhat.issues.wildfly.JmxServlet.doGet(JmxServlet.java:44)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 5 months
[JBoss JIRA] (JGRP-2138) Request.viewChange() implementations should not use View.getMembers()
by Dan Berindei (JIRA)
Dan Berindei created JGRP-2138:
----------------------------------
Summary: Request.viewChange() implementations should not use View.getMembers()
Key: JGRP-2138
URL: https://issues.jboss.org/browse/JGRP-2138
Project: JGroups
Issue Type: Bug
Reporter: Dan Berindei
Assignee: Bela Ban
Priority: Minor
{{Request.viewChange()}} is called once for every request, and {{View.getMembers()}} allocates 2 (small) objects. Both {{UnicastRequest}} and {{GroupRequest}} could use {{View.containsMember()}} instead.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 5 months