June 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-6767) security-realms that defer to jaas cannot load login-modules from org.jboss.as.security

by Derek Horton (JIRA)

[ https://issues.jboss.org/browse/WFLY-6767?page=com.atlassian.jira.plugin.... ] Derek Horton moved JBEAP-5114 to WFLY-6767: ------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-6767 (was: JBEAP-5114) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Target Release: (was: 7.backlog.GA) > security-realms that defer to jaas cannot load login-modules from org.jboss.as.security > ---------------------------------------------------------------------------------------- > > Key: WFLY-6767 > URL: https://issues.jboss.org/browse/WFLY-6767 > Project: WildFly > Issue Type: Bug > Reporter: Derek Horton > > security-realms that defer to jaas cannot load login-modules from org.jboss.as.security. The configuration looks like the following: > <security-realm name="ManagementRealm"> > <authentication> > <jaas name="jmx-console"/> > </authentication> > <authorization map-groups-to-roles="false"> > <properties path="mgmt-groups.properties" relative-to="jboss.server.config.dir"/> > </authorization> > </security-realm> > <security-domain name="jmx-console" cache-type="default"> > <authentication> > <login-module code="RealmUsersRoles" flag="required"> > <module-option name="rolesProperties" value="file://${jboss.server.config.dir}/rolesmapping.properties"/> > <module-option name="usersProperties" value="file://${jboss.server.config.dir}/rolesmapping.properties"/> > </login-module> > </authentication> > </security-domain> > The following error is logged during the authentication attempt: > 2016-06-23 11:17:27,680 DEBUG [org.jboss.security] (management task-1) PBOX00206: Login failure: javax.security.auth.login.LoginException: unable to find LoginModule class: org.jboss.as.security.RealmDirectLoginModule from [Module "org.jboss.as.server:main" from local module loader @42f30e0a (finder: local module finder @24273305 (roots: /home/dehort/dev/java/jboss-eap-7.0.0/modules,/home/dehort/dev/java/jboss-eap-7.0.0/modules/system/layers/base))] > 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.jboss.as.security.service.SimpleSecurityManager.authenticate(SimpleSecurityManager.java:406) > at org.jboss.as.security.service.SimpleSecurityManager.authenticate(SimpleSecurityManager.java:367) > at org.jboss.as.security.service.SimpleSecurityManager.authenticate(SimpleSecurityManager.java:347) > at org.jboss.as.domain.management.security.JaasCallbackHandler.handle(JaasCallbackHandler.java:174) > at org.jboss.as.domain.management.security.SecurityRealmService$1.handle(SecurityRealmService.java:175) > at org.jboss.as.domain.http.server.security.RealmIdentityManager.verify(RealmIdentityManager.java:162) > at org.jboss.as.domain.http.server.security.RealmIdentityManager.verify(RealmIdentityManager.java:141) > at io.undertow.security.impl.BasicAuthenticationMechanism.authenticate(BasicAuthenticationMechanism.java:161) > at org.jboss.as.domain.http.server.security.AuthenticationMechanismWrapper.authenticate(AuthenticationMechanismWrapper.java:52) > at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:233) > at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:250) > at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.access$100(SecurityContextImpl.java:219) > at io.undertow.security.impl.SecurityContextImpl.attemptAuthentication(SecurityContextImpl.java:121) > at io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:96) > at io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:89) > at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:50) > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202) > at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:792) > 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) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6766) Rejection-style transformer tests assume each operation generated by parser has distinct PathAddress

by Paul Ferraro (JIRA)

Paul Ferraro created WFLY-6766: ---------------------------------- Summary: Rejection-style transformer tests assume each operation generated by parser has distinct PathAddress Key: WFLY-6766 URL: https://issues.jboss.org/browse/WFLY-6766 Project: WildFly Issue Type: Bug Components: Test Suite Affects Versions: 10.0.0.Final Reporter: Paul Ferraro Assignee: Kabir Khan For rejection-style transformer tests, the subsystem test framework stores expected rejected operations in a map keyed by PathAddress. This is fine when the subsystem's parser only generates add operations. However, if the parser generates an add operation as well as a a write-attribute operation, these 2 operations will have the same path address. If we expect one of these operations to be rejected, but not the other, we end up with an unexpected rejection - and the test fails. This is a little hard to explain in the abstract, so let me know if any of the above doesn't make sense. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1606) Server reload is needed for modified security-realm even if {allow-resource-service-restart=true} is used

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1606?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1606: ------------------------------------- Fix Version/s: 3.0.0.Beta1 > Server reload is needed for modified security-realm even if {allow-resource-service-restart=true} is used > --------------------------------------------------------------------------------------------------------- > > Key: WFCORE-1606 > URL: https://issues.jboss.org/browse/WFCORE-1606 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management, Security > Affects Versions: 2.0.10.Final > Reporter: Ondrej Lukas > Fix For: 3.0.0.Beta1 > > > When security-realm, which is set as http-interface security-realm in management-interfaces, is modified and operation used {allow-resource-service-restart=true} header then server is NOT in reload-required state but modified security realm does not work correctly until server is manually reloaded. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2083) Specifying prefix in S3_PING or GOOGLE_PING causes property validation failures

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2083?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-2083: --------------------------- Fix Version/s: 3.6.10 4.0 > Specifying prefix in S3_PING or GOOGLE_PING causes property validation failures > ------------------------------------------------------------------------------- > > Key: JGRP-2083 > URL: https://issues.jboss.org/browse/JGRP-2083 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.6.9 > Reporter: Alan Field > Assignee: Bela Ban > Fix For: 3.6.10, 4.0 > > > S3_PING.validateProperties() has a check to verify that both location and prefix are not set, but the superclass FILE_PING sets the value for location. In order to use prefix, the location property has to be set to null which is not possible in all cases. See ISPN-5097 for details. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JBREM-1334) Failure on connection not detected.

by Doug Grove (JIRA)

[ https://issues.jboss.org/browse/JBREM-1334?page=com.atlassian.jira.plugin... ] Doug Grove updated JBREM-1334: ------------------------------ Description: Looking at BisocketServerInvoker.run(): {code} if (!t.checkConnection()) { t.shutdown(); synchronized (this) { if (!running) return; controlConnectionThreadMap.remove(listenerId); Object o = controlConnectionRestartsMap.get(listenerId); int restarts = ((Integer)o).intValue(); if (restarts + 1 > controlConnectionRestarts) { log.warn(this + ": detected failure on control connection " + t); log.warn("Control connection " + listenerId + " has been recreated " + restarts + " times."); log.warn("Assuming it is a connection to an old server, and will not restart"); controlConnectionRestartsMap.remove(listenerId); continue; } log.warn(this + ": detected failure on control connection " + t + " (" + listenerId + ": requesting new control connection"); } {code} It looks like the check never succeeds and " detected failure on control connection " is logged indefinitely. was: Lookin at BisocketServerInvoker.run(): {code} if (!t.checkConnection()) { t.shutdown(); synchronized (this) { if (!running) return; controlConnectionThreadMap.remove(listenerId); Object o = controlConnectionRestartsMap.get(listenerId); int restarts = ((Integer)o).intValue(); if (restarts + 1 > controlConnectionRestarts) { log.warn(this + ": detected failure on control connection " + t); log.warn("Control connection " + listenerId + " has been recreated " + restarts + " times."); log.warn("Assuming it is a connection to an old server, and will not restart"); controlConnectionRestartsMap.remove(listenerId); continue; } log.warn(this + ": detected failure on control connection " + t + " (" + listenerId + ": requesting new control connection"); } {code} It looks like the check never succeeds and " detected failure on control connection " is logged indefinitely. > Failure on connection not detected. > ----------------------------------- > > Key: JBREM-1334 > URL: https://issues.jboss.org/browse/JBREM-1334 > Project: JBoss Remoting > Issue Type: Bug > Affects Versions: 2.5.4.SP4 > Environment: Red Hat JBoss EAP 5.1.2 > Reporter: Doug Grove > > Looking at BisocketServerInvoker.run(): > {code} > if (!t.checkConnection()) > { > t.shutdown(); > > synchronized (this) > { > if (!running) > return; > > controlConnectionThreadMap.remove(listenerId); > Object o = controlConnectionRestartsMap.get(listenerId); > int restarts = ((Integer)o).intValue(); > > if (restarts + 1 > controlConnectionRestarts) > { > log.warn(this + ": detected failure on control connection " + t); > log.warn("Control connection " + listenerId + " has been recreated " + restarts + " times."); > log.warn("Assuming it is a connection to an old server, and will not restart"); > controlConnectionRestartsMap.remove(listenerId); > continue; > } > > log.warn(this + ": detected failure on control connection " + t + > " (" + listenerId + > ": requesting new control connection"); > } > {code} > It looks like the check never succeeds and " detected failure on control connection " is logged indefinitely. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JBREM-1334) Failure on connection not detected.

by Doug Grove (JIRA)

[ https://issues.jboss.org/browse/JBREM-1334?page=com.atlassian.jira.plugin... ] Doug Grove reassigned JBREM-1334: --------------------------------- Assignee: Ron Sigal > Failure on connection not detected. > ----------------------------------- > > Key: JBREM-1334 > URL: https://issues.jboss.org/browse/JBREM-1334 > Project: JBoss Remoting > Issue Type: Bug > Affects Versions: 2.5.4.SP4 > Environment: Red Hat JBoss EAP 5.1.2 > Reporter: Doug Grove > Assignee: Ron Sigal > > Looking at BisocketServerInvoker.run(): > {code} > if (!t.checkConnection()) > { > t.shutdown(); > > synchronized (this) > { > if (!running) > return; > > controlConnectionThreadMap.remove(listenerId); > Object o = controlConnectionRestartsMap.get(listenerId); > int restarts = ((Integer)o).intValue(); > > if (restarts + 1 > controlConnectionRestarts) > { > log.warn(this + ": detected failure on control connection " + t); > log.warn("Control connection " + listenerId + " has been recreated " + restarts + " times."); > log.warn("Assuming it is a connection to an old server, and will not restart"); > controlConnectionRestartsMap.remove(listenerId); > continue; > } > > log.warn(this + ": detected failure on control connection " + t + > " (" + listenerId + > ": requesting new control connection"); > } > {code} > It looks like the check never succeeds and " detected failure on control connection " is logged indefinitely. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JBREM-1334) Failure on connection not detected.

by Doug Grove (JIRA)

Doug Grove created JBREM-1334: --------------------------------- Summary: Failure on connection not detected. Key: JBREM-1334 URL: https://issues.jboss.org/browse/JBREM-1334 Project: JBoss Remoting Issue Type: Bug Affects Versions: 2.5.4.SP4 Environment: Red Hat JBoss EAP 5.1.2 Reporter: Doug Grove Lookin at BisocketServerInvoker.run(): {code} if (!t.checkConnection()) { t.shutdown(); synchronized (this) { if (!running) return; controlConnectionThreadMap.remove(listenerId); Object o = controlConnectionRestartsMap.get(listenerId); int restarts = ((Integer)o).intValue(); if (restarts + 1 > controlConnectionRestarts) { log.warn(this + ": detected failure on control connection " + t); log.warn("Control connection " + listenerId + " has been recreated " + restarts + " times."); log.warn("Assuming it is a connection to an old server, and will not restart"); controlConnectionRestartsMap.remove(listenerId); continue; } log.warn(this + ": detected failure on control connection " + t + " (" + listenerId + ": requesting new control connection"); } {code} It looks like the check never succeeds and " detected failure on control connection " is logged indefinitely. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1606) Server reload is needed for modified security-realm even if {allow-resource-service-restart=true} is used

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1606?page=com.atlassian.jira.plugi... ] Brian Stansberry reassigned WFCORE-1606: ---------------------------------------- Component/s: Security Assignee: (was: Brian Stansberry) > Server reload is needed for modified security-realm even if {allow-resource-service-restart=true} is used > --------------------------------------------------------------------------------------------------------- > > Key: WFCORE-1606 > URL: https://issues.jboss.org/browse/WFCORE-1606 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management, Security > Affects Versions: 2.0.10.Final > Reporter: Ondrej Lukas > > When security-realm, which is set as http-interface security-realm in management-interfaces, is modified and operation used {allow-resource-service-restart=true} header then server is NOT in reload-required state but modified security realm does not work correctly until server is manually reloaded. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1606) Server reload is needed for modified security-realm even if {allow-resource-service-restart=true} is used

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1606?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFCORE-1606: ------------------------------------------ When looking at this we should examine the possibility of actually supporting allow-resource-service-restart=true, as opposed to correcting the metadata. But this all ties in to the elytron migration as well, i.e. we shouldn't change the behavior of security-realm in a way that will be different from what the elytron subsystem stuff supports. > Server reload is needed for modified security-realm even if {allow-resource-service-restart=true} is used > --------------------------------------------------------------------------------------------------------- > > Key: WFCORE-1606 > URL: https://issues.jboss.org/browse/WFCORE-1606 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 2.0.10.Final > Reporter: Ondrej Lukas > Assignee: Brian Stansberry > > When security-realm, which is set as http-interface security-realm in management-interfaces, is modified and operation used {allow-resource-service-restart=true} header then server is NOT in reload-required state but modified security realm does not work correctly until server is manually reloaded. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1606) Server reload is needed for modified security-realm even if {allow-resource-service-restart=true} is used

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1606?page=com.atlassian.jira.plugi... ] Brian Stansberry edited comment on WFCORE-1606 at 6/23/16 1:37 PM: ------------------------------------------------------------------- [~iweiss] https://github.com/wildfly/wildfly-core/blob/master/domain-management/src... is wrong. SecurityRealmChildRemoveHandler does not support the allow-resource-service-restart=true header. I believe this is a common mistake in the uses of SecurityRealmParentRestartHandler; the first other one I checked had the same problem. was (Author: brian.stansberry): [~iweiss] https://github.com/wildfly/wildfly-core/blob/master/domain-management/src... is wrong. SecurityRealmChildRemoveHandler does not support the {allow-resource-service-restart=true} header. I believe this is a common mistake in the uses of SecurityRealmParentRestartHandler; the first other one I checked had the same problem. > Server reload is needed for modified security-realm even if {allow-resource-service-restart=true} is used > --------------------------------------------------------------------------------------------------------- > > Key: WFCORE-1606 > URL: https://issues.jboss.org/browse/WFCORE-1606 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 2.0.10.Final > Reporter: Ondrej Lukas > Assignee: Brian Stansberry > > When security-realm, which is set as http-interface security-realm in management-interfaces, is modified and operation used {allow-resource-service-restart=true} header then server is NOT in reload-required state but modified security realm does not work correctly until server is manually reloaded. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 4 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira June 2016