May 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-2809) Fix parsing and handling of the legacy username attribute for a remote-outbound-connection

by Farah Juma (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2809?page=com.atlassian.jira.plugi... ] Farah Juma updated WFCORE-2809: ------------------------------- Summary: Fix parsing and handling of the legacy username attribute for a remote-outbound-connection (was: Fix parsing and handling of the legacy username attribute specified for a remote-outbound-connection) > Fix parsing and handling of the legacy username attribute for a remote-outbound-connection > ------------------------------------------------------------------------------------------ > > Key: WFCORE-2809 > URL: https://issues.jboss.org/browse/WFCORE-2809 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Farah Juma > Assignee: Farah Juma > Priority: Blocker > > Currently, when the username attribute is not specified for a remote-outbound-connection (i.e., for the Elytron remote-outbound-connection case), the username is erroneously being treated as the string “undefined”. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-2809) Fix parsing and handling of the legacy username attribute specified for a remote-outbound-connection

by Farah Juma (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2809?page=com.atlassian.jira.plugi... ] Farah Juma moved JBEAP-10914 to WFCORE-2809: -------------------------------------------- Project: WildFly Core (was: JBoss Enterprise Application Platform) Key: WFCORE-2809 (was: JBEAP-10914) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Security (was: Security) > Fix parsing and handling of the legacy username attribute specified for a remote-outbound-connection > ---------------------------------------------------------------------------------------------------- > > Key: WFCORE-2809 > URL: https://issues.jboss.org/browse/WFCORE-2809 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Farah Juma > Assignee: Farah Juma > Priority: Blocker > > Currently, when the username attribute is not specified for a remote-outbound-connection (i.e., for the Elytron remote-outbound-connection case), the username is erroneously being treated as the string “undefined”. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-2746) Move elytron management security tests from full to core

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2746?page=com.atlassian.jira.plugi... ] James Perkins commented on WFCORE-2746: --------------------------------------- I'm not sure I follow the argument against #1. The idea would be something like this: {code:java} abstract class AbstractTest { @Test public test1(){} @Test public test2(){} @Test public test3(){} @Test public test4(){} } {code} {code:java} @RunsWith(Arquillian.class) @ServerSetup(Test1.ConfigureServer.class) public class Test1 extends AbstractTest { public static class ConfigureServer implements ServerSetupTask { @Override public void setup(ManagementClient client) throws Exception {} @Override public void tearDown(ManagementClient client) throws Exception {} } } {code} You'd just repeat the abstract implementation for each configuration you want to test. Again though without know which test this is I could be off basis. > Move elytron management security tests from full to core > -------------------------------------------------------- > > Key: WFCORE-2746 > URL: https://issues.jboss.org/browse/WFCORE-2746 > Project: WildFly Core > Issue Type: Task > Components: Domain Management, Security, Test Suite > Reporter: Brian Stansberry > > Since until recently the elytron subsystem wasn't part of the core feature pack, a lot of integration tests of its use ended up in the WildFly full testsuite instead of in core. This task is to get tests that are only testing core functionality moved into the core testsuite. Because that's the right thing to do, but also because it's useful in practice by eliminating a cause for messy coordinated changes to core and full such that code changes in core can be tested. > Corresponding Wildfly JIRA: https://issues.jboss.org/browse/WFLY-8723 > There are a number of aspects to this, for which I'll create subtasks. > Following is an initial list of tests that should be moved. *This is meant to be a living list, with things added as they are noticed.* So anyone should feel free to edit this JIRA description to add things to the list. > -org.jboss.as.test.integration.security.perimeter.* [2]- > -org.jboss.as.test.manualmode.mgmt.elytron.HttpMgmtInterfaceElytronAuthenticationTestCase- > -org.jboss.as.test.integration.domain.AbstractSlaveHCAuthenticationTestCase and subclasses.[1]- > org.jboss.as.test.integration.security.credentialreference [2] > integration/elytron/ > [1] One subclass of this is not related to elytron but should be moved to core too. I haven't looked closely but it uses vault, which may be why it is in full. But we can use vault in the core testsuite now. > [2] Currently using Arquillian. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-2808) The Remote Outbound Connection does not use an SSLContext from the injected SecurityRealm or AuthenticationContext

by Farah Juma (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2808?page=com.atlassian.jira.plugi... ] Farah Juma moved JBEAP-10912 to WFCORE-2808: -------------------------------------------- Project: WildFly Core (was: JBoss Enterprise Application Platform) Key: WFCORE-2808 (was: JBEAP-10912) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Security (was: Security) > The Remote Outbound Connection does not use an SSLContext from the injected SecurityRealm or AuthenticationContext > ------------------------------------------------------------------------------------------------------------------ > > Key: WFCORE-2808 > URL: https://issues.jboss.org/browse/WFCORE-2808 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Farah Juma > Assignee: Farah Juma > Priority: Blocker > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-8773) Update EjbClientContextSetupProcessor.RegistrationService#transformOne to make use of the SSLContext from the RemoteOutboundConnectionService

by Farah Juma (JIRA)

[ https://issues.jboss.org/browse/WFLY-8773?page=com.atlassian.jira.plugin.... ] Farah Juma updated WFLY-8773: ----------------------------- Summary: Update EjbClientContextSetupProcessor.RegistrationService#transformOne to make use of the SSLContext from the RemoteOutboundConnectionService (was: The Remote Outbound Connection does not use an SSLContext from the injected SecurityRealm or AuthenticationContext) > Update EjbClientContextSetupProcessor.RegistrationService#transformOne to make use of the SSLContext from the RemoteOutboundConnectionService > --------------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-8773 > URL: https://issues.jboss.org/browse/WFLY-8773 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Farah Juma > Assignee: Farah Juma > Priority: Blocker > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ELY-1156) LocalUserClient should not fail if NameCallback is unsupported when default authentication name is set

by David Lloyd (JIRA)

David Lloyd created ELY-1156: -------------------------------- Summary: LocalUserClient should not fail if NameCallback is unsupported when default authentication name is set Key: ELY-1156 URL: https://issues.jboss.org/browse/ELY-1156 Project: WildFly Elytron Issue Type: Enhancement Reporter: David Lloyd Priority: Minor The LocalUserClient mechanism should be tolerant of unsupported callbacks for name (and realm) when there are defaults available for the corresponding values. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-2806) Global domain config for unique GC log file name and path

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2806?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFCORE-2806: ------------------------------------------ Possibilities: 1) Where possible use a different expression resolver for these such that the standard ${jboss.server.xxx} properties available on the server are also available to the HC. This would only work if the expression is being resolved in a context where there is one and only one relevant server, i.e. during server launch. 2) A simpler variant of that would be <option value="-Xloggc:${jboss.domain.servers.dir}/${jboss.special.property.for.server.being.launched}/log/gc.log"/> That's simpler because now we don't have to worry about all the different standard ${jboss.server.xxx} properties and the different ways they can be configured. But the user has to understand this special property. 3) Another variant is to use special expression syntax instead of a special property: <option value="-Xloggc:${jboss.domain.servers.dir}/##server.name##/log/gc.log"/> But I don't like that at all as it opens up a whole can of worms where now we may need to check for that syntax elsewhere, need new expression resolution logic etc. The fly in the ointment for all of these is the "This would only work if the expression is being resolved in a context where there is one and only one relevant server, i.e. during server launch" bit. So something like this would not work normally: /host=master:read-resource(recursive=true,resolve-expressions=true) Even something more targeted would not work: /host=master/server-config=server-one/jvm=default:read-resource(recursive=true,resolve-expressions=true) This is because the read-resource op is generic. And adding a lot of exception logic to it to handle special cases is not likely to be feasible. > Global domain config for unique GC log file name and path > --------------------------------------------------------- > > Key: WFCORE-2806 > URL: https://issues.jboss.org/browse/WFCORE-2806 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Aaron Ogburn > Labels: domain-mode > > Customers often try to do something like the following in their server group for domain mode to easily get a unique gc log path for all server group members: > {code} > <option value="-Xloggc:${jboss.server.log.dir}/gc.log"/> > {code} > But jboss.server.log.dir can't be resolved at that point so it fails. The next best thing that can be done is: > {code} > <option value="-Xloggc:${jboss.domain.servers.dir}/server-name/log/gc.log"/> > {code} > But then that has to be set for each server. It'd help if domain mode had some way of easily setting a gc.log path in a server-group level or higher that could be set once and result in unique gc log paths for all servers in the server-group. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (REMJMX-139) Unify default wildfly-config.xml across clients (Elytron)

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/REMJMX-139?page=com.atlassian.jira.plugin... ] Darran Lofthouse moved JBEAP-10911 to REMJMX-139: ------------------------------------------------- Project: Remoting JMX (was: JBoss Enterprise Application Platform) Key: REMJMX-139 (was: JBEAP-10911) Workflow: classic default workflow (was: CDW with loose statuses v1) Component/s: Security (was: Security) Affects Version/s: (was: 7.1.0.DR11) Fix Version/s: 3.0.0.Beta4 (was: 7.1.0.DR18) > Unify default wildfly-config.xml across clients (Elytron) > --------------------------------------------------------- > > Key: REMJMX-139 > URL: https://issues.jboss.org/browse/REMJMX-139 > Project: Remoting JMX > Issue Type: Bug > Components: Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Blocker > Labels: authentication-client, wildfly-config > Fix For: 3.0.0.Beta4 > > > Some client facing JARs contains default Elytron client configuration in `META-INF/wildfly-config.xml`: > {code} > bin/client/jboss-cli-client.jar > bin/client/jboss-client.jar > modules/system/layers/base/org/jboss/as/protocol/main/wildfly-protocol-3.0.0.Alpha22-redhat-1.jar > modules/system/layers/base/org/jboss/as/remoting/main/wildfly-remoting-3.0.0.Alpha22-redhat-1.jar > modules/system/layers/base/org/jboss/as/cli/main/wildfly-cli-3.0.0.Alpha22-redhat-1.jar > modules/system/layers/base/org/jboss/remoting-jmx/main/remoting-jmx-3.0.0.Beta2-redhat-1.jar > modules/system/layers/base/org/jboss/ejb-client/main/jboss-ejb-client-3.0.0.Beta4-redhat-1.jar > {code} > The configuration across the libraries is not unified, which could lead to different configuration used for different classpath ordering. > The issue is mainly with set of allowed SASL mechanisms across the libraries. Here are fragments of mechanism filtering used in the mentioned files: > {code:xml} > <allow-all-sasl-mechanisms /> > <allow-sasl-mechanisms names="JBOSS-LOCAL-USER EXTERNAL DIGEST-MD5 PLAIN ANONYMOUS" /> > <allow-sasl-mechanisms names="JBOSS-LOCAL-USER DIGEST-MD5 PLAIN ANONYMOUS" /> > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-2804) Elytron key-managers: operations do not reflect alias-filter attribute

by Michal Petrov (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2804?page=com.atlassian.jira.plugi... ] Michal Petrov commented on WFCORE-2804: --------------------------------------- There's a problem with the XML writer, the attribute isn't being written into the configuration. > Elytron key-managers: operations do not reflect alias-filter attribute > ---------------------------------------------------------------------- > > Key: WFCORE-2804 > URL: https://issues.jboss.org/browse/WFCORE-2804 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 3.0.0.Beta21 > Reporter: Ondrej Kotek > Assignee: Michal Petrov > > Operations {{add}} and {{write-attribute}} of Elytron {{key-managers}} do not reflect {{alias-filter}} attribute, see steps to reproduce. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-2804) Elytron key-managers: operations do not reflect alias-filter attribute

by Michal Petrov (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2804?page=com.atlassian.jira.plugi... ] Michal Petrov reassigned WFCORE-2804: ------------------------------------- Assignee: Michal Petrov > Elytron key-managers: operations do not reflect alias-filter attribute > ---------------------------------------------------------------------- > > Key: WFCORE-2804 > URL: https://issues.jboss.org/browse/WFCORE-2804 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 3.0.0.Beta21 > Reporter: Ondrej Kotek > Assignee: Michal Petrov > > Operations {{add}} and {{write-attribute}} of Elytron {{key-managers}} do not reflect {{alias-filter}} attribute, see steps to reproduce. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

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