February 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-1441) Threads resource classes should make it easy for users to declare capabilities

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1441?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1441: ------------------------------------- Fix Version/s: 3.0.0.Beta4 (was: 3.0.0.Beta3) > Threads resource classes should make it easy for users to declare capabilities > ------------------------------------------------------------------------------ > > Key: WFCORE-1441 > URL: https://issues.jboss.org/browse/WFCORE-1441 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Reporter: Brian Stansberry > Fix For: 3.0.0.Beta4 > > > The classes in the threads modules are now meant for shared use by subsystems in setting up consistent management of thread related resources. An important aspect of that management is the declaration of capabilities, particularly for use in capability-driven model integrity checking. > But the threads module classes do not include any hooks to let the calling code specify the relevant capabilities. > Things probably needed: > 1) Ability to declare the capability that should be registered when a resource is created. > 2) Ability to declare the capability that model reference attributes in a resource refer to. > Perhaps others, but those are the ones that come immediately to mind. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1960) Get rid of attributes of type LIST of PROPERTY; use OBJECT of STRING

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1960?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1960: ------------------------------------- Fix Version/s: 3.0.0.Beta4 (was: 3.0.0.Beta3) > Get rid of attributes of type LIST of PROPERTY; use OBJECT of STRING > -------------------------------------------------------------------- > > Key: WFCORE-1960 > URL: https://issues.jboss.org/browse/WFCORE-1960 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Ken Wills > Fix For: 3.0.0.Beta4 > > Attachments: rrd.txt > > > A read-resource-description output of a standalone-full-ha.xml server (see attached) shows a couple attributes that are of type LIST, value-type PROPERTY. (Just text search for PROPERTY.) We should convert those to OBJECT, value-type STRING. Both represent a resource address. An object of string is equivalent to a LinkedHashMap<String, String>, with ordering based on insertion. So such a description is fine for a path address attribute. > I'd like to get rid of the notion of PROPERTY in our spec definition of how to describe attributes, parameters and value-types (https://docs.jboss.org/author/display/WFLY/Description+of+the+Management+...) so removing the only usage of it will help. > We should still accept PROPERTY as inputs when we can do conversion to the defined type. This is all about tightening up the spec to remove the not-really-necessary PROPERTY concept. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1958) Clean up testsuite Elytron registration

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1958?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1958: ------------------------------------- Fix Version/s: 3.0.0.Beta4 (was: 3.0.0.Beta3) > Clean up testsuite Elytron registration > --------------------------------------- > > Key: WFCORE-1958 > URL: https://issues.jboss.org/browse/WFCORE-1958 > Project: WildFly Core > Issue Type: Task > Components: Test Suite > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Blocker > Fix For: 3.0.0.Beta4 > > > In a couple of places we have artificially registered the WildFly Elytron Security provider, we need to address this so tests can automatically have it available to them.. > Also re-enable the following test case: - > * org.jboss.as.test.integration.domain.suites.FullRbacProviderRunAsTestSuite -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1944) Convert domain-management tests to reference Elytron SecurityRealm and remove old CallbackHandler code.

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1944?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1944: ------------------------------------- Fix Version/s: 3.0.0.Beta4 (was: 3.0.0.Beta3) > Convert domain-management tests to reference Elytron SecurityRealm and remove old CallbackHandler code. > ------------------------------------------------------------------------------------------------------- > > Key: WFCORE-1944 > URL: https://issues.jboss.org/browse/WFCORE-1944 > Project: WildFly Core > Issue Type: Task > Components: Domain Management, Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 3.0.0.Beta4 > > > The important pieces of code within the legacy security realms are being wrapped using Elytron components, items like the legacy CallbackHandlers can be removed but existing tests need porting to call Elytron APIs. > The legacy tests do need to be retained as they offer a good level of regression testing for the legacy realms. -- 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 Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1964?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1964: ------------------------------------- Fix Version/s: 3.0.0.Beta4 (was: 3.0.0.Beta3) > 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.Beta4 > > > 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-1897) Follow up WFCORE-296 once migrated to Remoting 5

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1897?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1897: ------------------------------------- Fix Version/s: 3.0.0.Beta4 (was: 3.0.0.Beta3) > Follow up WFCORE-296 once migrated to Remoting 5 > ------------------------------------------------ > > Key: WFCORE-1897 > URL: https://issues.jboss.org/browse/WFCORE-1897 > Project: WildFly Core > Issue Type: Task > Components: Remoting > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Blocker > Fix For: 3.0.0.Beta4 > > > WFCORE-296 adds support for the schemes remote:// remote_http:// and remote+https:// - once we switch to centralised Endpoints we need to ensure this new set is still supported along with the previous set. -- 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 Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2071?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-2071: ------------------------------------- Fix Version/s: 3.0.0.Beta4 (was: 3.0.0.Beta3) > 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.Beta4 > > > 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-2068) HTTPSConnectionWithCLITestCase and HTTPSManagementInterfaceTestCase Failing Due To Native Protocol Issue

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2068?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-2068: ------------------------------------- Fix Version/s: 3.0.0.Beta4 (was: 3.0.0.Beta3) > 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.Beta4 > > > 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 Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2046?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-2046: ------------------------------------- Fix Version/s: 3.0.0.Beta4 (was: 3.0.0.Beta3) > 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.Beta4 > > 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 Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2016?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-2016: ------------------------------------- Fix Version/s: 3.0.0.Beta4 (was: 3.0.0.Beta3) > 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.Beta4 > > > 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

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