May 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (ELY-1132) Unable to load passwords from wildfly-config.xml

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-1132?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse updated ELY-1132: ---------------------------------- Fix Version/s: 1.1.0.Beta43 > Unable to load passwords from wildfly-config.xml > ------------------------------------------------ > > Key: ELY-1132 > URL: https://issues.jboss.org/browse/ELY-1132 > Project: WildFly Elytron > Issue Type: Bug > Reporter: Stuart Douglas > Assignee: Darran Lofthouse > Fix For: 1.1.0.Beta43 > > > I see the following exception, adding use-service-loader-providers does not help > Caused by: java.security.NoSuchAlgorithmException: ELY08028: Invalid algorithm "clear" > at org.wildfly.security.password.PasswordFactory.getInstance(PasswordFactory.java:121) > at org.wildfly.security.auth.client.ElytronXmlParser.lambda$parseClearPassword$47(ElytronXmlParser.java:2009) > ... 46 more > Looks like this should just be hard coded to use the Elytron provider? -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

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: --------------------------------------- There's at least a few different ways it could be dealt with. # The easiest would be making them separate tests. You just put the test methods in an abstract class with different {{@BeforeClass}} for each configuration. # You could make the 4 test logic methods private, configure the correct context on the HTTP interface, then invoke each logic test method. # This is also not my favorite, buy you could use the {{(a)FixMethodOrder(MethodSorters.NAME_ASCENDING)}} annotation in JUnit. The only real benefit here is it wouldn't require a new annotation. Though I do suppose a sequence annotation is easier to read if you're looking at the test for the first time. Don't get me wrong I think not reloading the server for each test is a good thing. I think option 1 or 2 would solve the issue with not having to add a new annotation though. If you give me the name of the test I'd be happy to have a look at it. Maybe in this case some kind of sequence annotation makes sense and I'm just missing the point. > 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, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8761) Deprecate modcluster subsystem /ssl=configuration resource

by Radoslav Husar (JIRA)

Radoslav Husar created WFLY-8761: ------------------------------------ Summary: Deprecate modcluster subsystem /ssl=configuration resource Key: WFLY-8761 URL: https://issues.jboss.org/browse/WFLY-8761 Project: WildFly Issue Type: Bug Components: mod_cluster Affects Versions: 11.0.0.Alpha1 Reporter: Radoslav Husar Assignee: Radoslav Husar The legacy SSL configuration resource, {{/subsystem=modcluster/mod-cluster-config=configuration/ssl=configuration}}, should be deprecated in favor of ssl-context=".." elytron reference. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1632) Server processing request isn't stopped immediately but waits for request processing to finish

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1632?page=com.atlassian.jira.plugi... ] Brian Stansberry reassigned WFCORE-1632: ---------------------------------------- Assignee: Brian Stansberry (was: Lin Gao) > Server processing request isn't stopped immediately but waits for request processing to finish > ---------------------------------------------------------------------------------------------- > > Key: WFCORE-1632 > URL: https://issues.jboss.org/browse/WFCORE-1632 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management, IO, Server > Reporter: Lin Gao > Assignee: Brian Stansberry > Priority: Critical > Original Estimate: 1 day > Remaining Estimate: 1 day > > When stopping server which is processing request, it terminates the connection from the client but doesn't stop the request processing as such. > After debugging and searching when the issue appeared I've found out that the issue was introduced with this commit: [https://github.com/wildfly/wildfly-core/commit/7304c019705c5f7ec0378e1c51...] > Steps to reproduce: > 1) start EAP server with deployed app from attachment > 2) create request to long running application: {{curl -i http://127.0.0.1:8080/long-running-servlet/HeavyProcessing?duration=25000}} > 3) stop server (you can do it even gracefully) using {{./jboss-cli.sh -c ":shutdown(timeout=1)"}} > See that server is stopped after 25 seconds since request from step 2 was issued, as that is duration of the request processing requested by param duration, instead of being terminated after 1 second. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (HAWKULARQE-15) [QE] - JMAN4-163 - Track EAP servers connecting to the middleware manager

by Matt Mahoney (JIRA)

[ https://issues.jboss.org/browse/HAWKULARQE-15?page=com.atlassian.jira.plu... ] Matt Mahoney updated HAWKULARQE-15: ----------------------------------- Comment: was deleted (was: CR1 regression:[ https://bugzilla.redhat.com/show_bug.cgi?id=1450201|http://example.com] ) > [QE] - JMAN4-163 - Track EAP servers connecting to the middleware manager > -------------------------------------------------------------------------- > > Key: HAWKULARQE-15 > URL: https://issues.jboss.org/browse/HAWKULARQE-15 > Project: Hawkular QE > Issue Type: Task > Reporter: Hayk Hovsepyan > Assignee: Matt Mahoney > Labels: mm-integration-hawkular-qe > > See [JMAN4-163|https://issues.jboss.org/browse/JMAN4-163] -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (HAWKULARQE-15) [QE] - JMAN4-163 - Track EAP servers connecting to the middleware manager

by Matt Mahoney (JIRA)

[ https://issues.jboss.org/browse/HAWKULARQE-15?page=com.atlassian.jira.plu... ] Matt Mahoney updated HAWKULARQE-15: ----------------------------------- CR1 Regression: https://bugzilla.redhat.com/show_bug.cgi?id=1450201 > [QE] - JMAN4-163 - Track EAP servers connecting to the middleware manager > -------------------------------------------------------------------------- > > Key: HAWKULARQE-15 > URL: https://issues.jboss.org/browse/HAWKULARQE-15 > Project: Hawkular QE > Issue Type: Task > Reporter: Hayk Hovsepyan > Assignee: Matt Mahoney > Labels: mm-integration-hawkular-qe > > See [JMAN4-163|https://issues.jboss.org/browse/JMAN4-163] -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ELY-1152) Rework security Provider behaviour

by Darran Lofthouse (JIRA)

Darran Lofthouse created ELY-1152: ------------------------------------- Summary: Rework security Provider behaviour Key: ELY-1152 URL: https://issues.jboss.org/browse/ELY-1152 Project: WildFly Elytron Issue Type: Task Components: Authentication Client Reporter: Darran Lofthouse Assignee: Darran Lofthouse Priority: Critical Everything that makes use of providers should be using a Supplier<Provider[]> which exists as a result of parsing the configuration. Our default behaviour should likely be a combination of globally defined providers, and service loader discovered providers. Config then is more likely to be about disabling one or both rather than enabling. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8760) get method of ModuleClassLoaderLocator requires createClassLoader permission

by Ondrej Lukas (JIRA)

[ https://issues.jboss.org/browse/WFLY-8760?page=com.atlassian.jira.plugin.... ] Ondrej Lukas updated WFLY-8760: ------------------------------- Description: There is missing doPriviliged block in ModuleClassLoaderLocator. Fix of WFLY-7412 for ModuleClassLoaderLocator introduces new CombinedClassLoader innner class which extends SecureClassLoader. Initialization of this class needs to createClassLoader RuntimePermission. That means: * All deployment which uses API which internally uses ModuleClassLoaderLocator needs createClassLoader RuntimePermission (which is new in EAP 7.1, the same deployments in EAP 7.0 does not need this permission) ** i.e. getMappingContext(String mappingType) in org.jboss.security.plugins.mapping.JBossMappingManager works internally with ModuleClassLoaderLocator. * setting createClassLoader RuntimePermission for deployment can be dangerous and it should probably use own permission was: There is missing doPriviliged block in ModuleClassLoaderLocator. Fix of JBEAP-6559 for ModuleClassLoaderLocator introduces new CombinedClassLoader innner class which extends SecureClassLoader. Initialization of this class needs to createClassLoader RuntimePermission. That means: * All deployment which uses API which internally uses ModuleClassLoaderLocator needs createClassLoader RuntimePermission (which is new in EAP 7.1, the same deployments in EAP 7.0 does not need this permission) ** i.e. getMappingContext(String mappingType) in org.jboss.security.plugins.mapping.JBossMappingManager works internally with ModuleClassLoaderLocator. * setting createClassLoader RuntimePermission for deployment can be dangerous and it should probably use own permission > get method of ModuleClassLoaderLocator requires createClassLoader permission > ---------------------------------------------------------------------------- > > Key: WFLY-8760 > URL: https://issues.jboss.org/browse/WFLY-8760 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > Priority: Critical > > There is missing doPriviliged block in ModuleClassLoaderLocator. Fix of WFLY-7412 for ModuleClassLoaderLocator introduces new CombinedClassLoader innner class which extends SecureClassLoader. Initialization of this class needs to createClassLoader RuntimePermission. > That means: > * All deployment which uses API which internally uses ModuleClassLoaderLocator needs createClassLoader RuntimePermission (which is new in EAP 7.1, the same deployments in EAP 7.0 does not need this permission) > ** i.e. getMappingContext(String mappingType) in org.jboss.security.plugins.mapping.JBossMappingManager works internally with ModuleClassLoaderLocator. > * setting createClassLoader RuntimePermission for deployment can be dangerous and it should probably use own permission -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8760) get method of ModuleClassLoaderLocator requires createClassLoader permission

by Ondrej Lukas (JIRA)

Ondrej Lukas created WFLY-8760: ---------------------------------- Summary: get method of ModuleClassLoaderLocator requires createClassLoader permission Key: WFLY-8760 URL: https://issues.jboss.org/browse/WFLY-8760 Project: WildFly Issue Type: Bug Components: Security Reporter: Ondrej Lukas Assignee: Darran Lofthouse Priority: Critical There is missing doPriviliged block in ModuleClassLoaderLocator. Fix of JBEAP-6559 for ModuleClassLoaderLocator introduces new CombinedClassLoader innner class which extends SecureClassLoader. Initialization of this class needs to createClassLoader RuntimePermission. That means: * All deployment which uses API which internally uses ModuleClassLoaderLocator needs createClassLoader RuntimePermission (which is new in EAP 7.1, the same deployments in EAP 7.0 does not need this permission) ** i.e. getMappingContext(String mappingType) in org.jboss.security.plugins.mapping.JBossMappingManager works internally with ModuleClassLoaderLocator. * setting createClassLoader RuntimePermission for deployment can be dangerous and it should probably use own permission -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2672) list-add doesn't work for principal-query attribute of jdbc-realm

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2672?page=com.atlassian.jira.plugi... ] Darran Lofthouse updated WFCORE-2672: ------------------------------------- Fix Version/s: 3.0.0.Beta22 > list-add doesn't work for principal-query attribute of jdbc-realm > ----------------------------------------------------------------- > > Key: WFCORE-2672 > URL: https://issues.jboss.org/browse/WFCORE-2672 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Michal Petrov > Assignee: Michal Petrov > Priority: Critical > Fix For: 3.0.0.Beta22 > > > Previously it was possible to use the list-add, list-remove operations to add and remove items from a principal-query (type LIST), but doesn't work at the recent version: > The list operation is important for web console, as it should manipulate the list items individually, instead to use write-attribute as this is going to handle all items in the list. > Add a jdbc-realm > {code} > /profile=full/subsystem=elytron/jdbc-realm=jdbc3:add(principal-query=[{data-source=ExampleDS,sql="select test from table"}]) > {code} > Display its content > {code} > /profile=full/subsystem=elytron/jdbc-realm=jdbc3:list-get(name=principal-query,index=0) > { > "outcome" => "success", > "result" => { > "data-source" => "ExampleDS", > "sql" => "select test from table" > } > } > {code} > However to add more principal-query items doesn't work > {code} > /profile=full/subsystem=elytron/jdbc-realm=jdbc3:list-add(name=principal-query,value={sql="select other from table2",data-source="ExampleDS"}) > { > "outcome" => "failed", > "failure-description" => {"domain-failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.IllegalArgumentException"}, > "rolled-back" => true > } > {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 May 2017