February 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-2068) HTTPSConnectionWithCLITestCase and HTTPSManagementInterfaceTestCase Failing Due To Native Protocol Issue

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2068?page=com.atlassian.jira.plugi... ] Kabir Khan updated WFCORE-2068: ------------------------------- Fix Version/s: 3.0.0.Beta2 (was: 3.0.0.Beta1) > HTTPSConnectionWithCLITestCase and HTTPSManagementInterfaceTestCase Failing Due To Native Protocol Issue > -------------------------------------------------------------------------------------------------------- > > Key: WFCORE-2068 > URL: https://issues.jboss.org/browse/WFCORE-2068 > Project: WildFly Core > Issue Type: Bug > Components: Remoting, Test Suite > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Blocker > Fix For: 3.0.0.Beta2 > > > The listed test case is failing during clean up with the following error: - > {noformat} > java.io.IOException: java.io.IOException: WFLYPRT0054: Channel closed > at org.jboss.as.protocol.mgmt.ManagementClientChannelStrategy$Establishing.getChannel(ManagementClientChannelStrategy.java:166) > at org.jboss.as.controller.client.impl.RemotingModelControllerClient.getOrCreateChannel(RemotingModelControllerClient.java:135) > at org.jboss.as.controller.client.impl.RemotingModelControllerClient$1.getChannel(RemotingModelControllerClient.java:59) > at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:135) > at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:110) > at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeRequest(AbstractModelControllerClient.java:263) > at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:168) > at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:147) > at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:80) > {noformat} > The stage of the test using HTTP Upgrade over a HTTPS connection appears to be working fine, the issue is with the native management interface used for test clean up. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2046) KeyManager synchronization issue when using IBM JDK

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2046?page=com.atlassian.jira.plugi... ] Kabir Khan updated WFCORE-2046: ------------------------------- Fix Version/s: 3.0.0.Beta2 (was: 3.0.0.Beta1) > KeyManager synchronization issue when using IBM JDK > --------------------------------------------------- > > Key: WFCORE-2046 > URL: https://issues.jboss.org/browse/WFCORE-2046 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Josef Cacek > Assignee: Darran Lofthouse > Priority: Blocker > Fix For: 3.0.0.Beta2 > > Attachments: test-app-ibm-jdk-keymanager-sync.zip > > > We hit a {{KeyManagerFactory}} related synchronization issue in {{org.jboss.as.domain.management.security.AbstractKeyManagerService.createKeyManagers(boolean)}} method on IBM JDK. The issue occurs if there are more security realms with SSL identities in EAP and they have keystores with different passwords. > As the ApplicationRealm (in EAP 7.1) has preconfigured ssl identity configuration, the risk customers will hit this when they add their own security realm with a ssl identity is big. The frequency we hit this issue is more than 10% cases on our machines. > Our debugging suggests the problem is located in IBM JDK implementation of {{javax.net.ssl.KeyManagerFactorySpi}} (class {{com.ibm.jsse2.ae$a}}). > The workflow: > # user calls {{keyManagerFactory.init(keyStore, keystorePassword)}} which invokes {{com.ibm.jsse2.ae$a.engineInit(Keystore keyStore, char[] password)}} > # the password (from the second method parameter) is stored into static field {{com.ibm.jsse2.ae.d}} and in the next step the field is used as parameter for creating new object {{new com.ibm.jsse2.aw(keyStore, d)}} > # the previous step is not synchronized and when more threads call {{keyManagerFactory.init()}} with different passwords, wrong password may be used for retrieving a key from keystore. > *Possible workaround* > We could workaround this issue on EAP side (until it's fixed in the JDK) by synchronizing {{keyManagerFactory.init()}} call in {{AbstractKeyManagerService.createKeyManagers(boolean)}} when IBM JDK is used. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2016) Change sasl-authentication-factor for management auth works after reload, but not after server restart

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2016?page=com.atlassian.jira.plugi... ] Kabir Khan updated WFCORE-2016: ------------------------------- Fix Version/s: 3.0.0.Beta2 (was: 3.0.0.Beta1) > Change sasl-authentication-factor for management auth works after reload, but not after server restart > ------------------------------------------------------------------------------------------------------ > > Key: WFCORE-2016 > URL: https://issues.jboss.org/browse/WFCORE-2016 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management, Security > Reporter: Zach Rhoads > Assignee: Darran Lofthouse > Fix For: 3.0.0.Beta2 > > > I can successfully configure a new sasl-authentication-factory and assign it to the management interface: > {code} > /subsystem=elytron/filesystem-realm=exampleFsRealm:add(path=fs-realm-users,relative-to=jboss.server.config.dir) > /subsystem=elytron/filesystem-realm=exampleFsRealm/identity=user1:add() > /subsystem=elytron/filesystem-realm=exampleFsRealm/identity=user1:set-password(clear={password="password123"}) > /subsystem=elytron/filesystem-realm=exampleFsRealm/identity=user1:add-attribute(name=Roles, value=["Admin","Guest"]) > /subsystem=elytron/simple-role-decoder=from-roles-attribute:add(attribute=Roles) > /subsystem=elytron/security-domain=exampleFsSD:add(realms=[{realm=exampleFsRealm,role-decoder=from-roles-attribute}],default-realm=exampleFsRealm,permission-mapper=login-permission-mapper) > /subsystem=elytron/sasl-authentication-factory=example-sasl-auth:add(sasl-server-factory=configured,security-domain=exampleFsSD,mechanism-configurations=[{mechanism-name=DIGEST-MD5,mechanism-realm-configurations=[{realm-name=exampleSaslRealm}]}]) > /core-service=management/management-interface=http-interface:write-attribute(name=http-upgrade.sasl-authentication-factory, value=example-sasl-auth) > reload > {code} > after reload, i am forced to re-authenticate and it succeeds: > {code} > [standalone@localhost:9990 /] reload > Authenticating against security realm: exampleSaslRealm > Username: user1 > Password: > [standalone@localhost:9990 /] > {code} > Once i restart the server though and try to connect, i get a timeout: > {code} > $ ./jboss-cli.sh -c > Failed to connect to the controller: The controller is not available at localhost:9990: java.net.ConnectException: WFLYPRT0023: Could not connect to remote+http://localhost:9990. The connection timed out: WFLYPRT0023: Could not connect to remote+http://localhost:9990. The connection timed out > {code} > It also fails if i force no local auth: > {code} > $ ./jboss-cli.sh -c --no-local-auth > Failed to connect to the controller: The controller is not available at localhost:9990: java.net.ConnectException: WFLYPRT0023: Could not connect to remote+http://localhost:9990. The connection timed out: WFLYPRT0023: Could not connect to remote+http://localhost:9990. The connection timed out > {code}/ -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1965) Remove the jboss-logging-annotations dependency from the core feature pack.

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1965?page=com.atlassian.jira.plugi... ] Kabir Khan updated WFCORE-1965: ------------------------------- Fix Version/s: 3.0.0.Beta2 (was: 3.0.0.Beta1) > Remove the jboss-logging-annotations dependency from the core feature pack. > --------------------------------------------------------------------------- > > Key: WFCORE-1965 > URL: https://issues.jboss.org/browse/WFCORE-1965 > Project: WildFly Core > Issue Type: Task > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Critical > Fix For: 3.0.0.Beta2 > > > This was added inadvertently with some other changes: - > {noformat} > <dependency> > <groupId>org.jboss.logging</groupId> > <artifactId>jboss-logging-annotations</artifactId> > </dependency> > {noformat} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1964) Internal ModelControllerClient should bypass access control by default

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1964?page=com.atlassian.jira.plugi... ] Kabir Khan updated WFCORE-1964: ------------------------------- Fix Version/s: 3.0.0.Beta2 (was: 3.0.0.Beta1) > Internal ModelControllerClient should bypass access control by default > ---------------------------------------------------------------------- > > Key: WFCORE-1964 > URL: https://issues.jboss.org/browse/WFCORE-1964 > Project: WildFly Core > Issue Type: Task > Components: Domain Management, Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Blocker > Fix For: 3.0.0.Beta2 > > > This is continuing compatibility where in-vm clients can perform actions without triggering management access control. > It would be nice also if we could find a way to make it possible to selectively disable this for cases where we want identity propagation between applications and the management tier. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2136) Using management CLI with client configuration still prompts for username/password

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2136?page=com.atlassian.jira.plugi... ] Kabir Khan updated WFCORE-2136: ------------------------------- Fix Version/s: 3.0.0.Beta2 (was: 3.0.0.Beta1) > Using management CLI with client configuration still prompts for username/password > ---------------------------------------------------------------------------------- > > Key: WFCORE-2136 > URL: https://issues.jboss.org/browse/WFCORE-2136 > Project: WildFly Core > Issue Type: Bug > Components: CLI, Security > Reporter: Zach Rhoads > Assignee: Darran Lofthouse > Fix For: 3.0.0.Beta2 > > > When configuring the wildfly management cli to use an elytron client config file, server still prompts for username password. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2101) Ensure the default configurations used by clients will be compatible with stronger authentication mechanisms

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2101?page=com.atlassian.jira.plugi... ] Kabir Khan updated WFCORE-2101: ------------------------------- Fix Version/s: 3.0.0.Beta2 (was: 3.0.0.Beta1) > Ensure the default configurations used by clients will be compatible with stronger authentication mechanisms > ------------------------------------------------------------------------------------------------------------ > > Key: WFCORE-2101 > URL: https://issues.jboss.org/browse/WFCORE-2101 > Project: WildFly Core > Issue Type: Task > Components: Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Blocker > Fix For: 3.0.0.Beta2 > > > i.e. a later AS release will start to enable mechs like SCRAM, client should work without additional configuration. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2100) Upgrade to WildFly Elytron 1.1.0.Final

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2100?page=com.atlassian.jira.plugi... ] Kabir Khan updated WFCORE-2100: ------------------------------- Fix Version/s: 3.0.0.Beta2 (was: 3.0.0.Beta1) > Upgrade to WildFly Elytron 1.1.0.Final > -------------------------------------- > > Key: WFCORE-2100 > URL: https://issues.jboss.org/browse/WFCORE-2100 > Project: WildFly Core > Issue Type: Component Upgrade > Components: Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 3.0.0.Beta2 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2071) Properly handle unknown roles instead of throwing exception

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2071?page=com.atlassian.jira.plugi... ] Kabir Khan updated WFCORE-2071: ------------------------------- Fix Version/s: 3.0.0.Beta2 (was: 3.0.0.Beta1) > Properly handle unknown roles instead of throwing exception > ----------------------------------------------------------- > > Key: WFCORE-2071 > URL: https://issues.jboss.org/browse/WFCORE-2071 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Pedro Igor > Assignee: Darran Lofthouse > Fix For: 3.0.0.Beta2 > > > When mapping roles directly from the identity: > {code} > <access-control provider="rbac" use-identity-roles="true"/> > {code} > If the identity has a role that is not known, a {{UnknowRoleException}} is thrown. > Ideally, we should just ignore unknown roles. Or is there any reason for this check ? -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2267) Delete all legacy code from CallbackHandlerService and SubjectSupplemental implementations

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2267?page=com.atlassian.jira.plugi... ] Kabir Khan updated WFCORE-2267: ------------------------------- Fix Version/s: 3.0.0.Beta2 (was: 3.0.0.Beta1) > Delete all legacy code from CallbackHandlerService and SubjectSupplemental implementations > ------------------------------------------------------------------------------------------ > > Key: WFCORE-2267 > URL: https://issues.jboss.org/browse/WFCORE-2267 > Project: WildFly Core > Issue Type: Task > Components: Domain Management, Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 3.0.0.Beta2 > > > Only the Elytron realms are now used. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira February 2017