[JBoss JIRA] (WFCORE-657) CLI embedded server does not always clean up properly
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFCORE-657?page=com.atlassian.jira.plugin... ]
Kabir Khan updated WFCORE-657:
------------------------------
Fix Version/s: 1.0.0.CR1
(was: 1.0.0.Beta6)
> CLI embedded server does not always clean up properly
> -----------------------------------------------------
>
> Key: WFCORE-657
> URL: https://issues.jboss.org/browse/WFCORE-657
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Affects Versions: 1.0.0.Beta1
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: 1.0.0.CR1
>
>
> While looking at some other test issues I noticed test logging that indicates that the server embedded in the CLI seems to not always be cleaning up properly, resulting in MSC leaving mbeans installed and subsequent mbean registration errors when the next attempt to launch happens.
> Here's an example from a server.log; my impression is one test method attempts to create a server with an invalid --empty-config param, and when that fails the appropriate cleanup doesn't happen.
> {code}
> 2015-04-20 11:27:44,020 ERROR [org.jboss.msc.service.fail] (MSC service thread 17-1) MSC000001: Failed to start service jboss.as.server-controller: org.jboss.msc.service.StartException in service jboss.as.server-controller: Failed to start service
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:744)
> Caused by: java.lang.IllegalStateException: WFLYCTL0389: Could not create an empty configuration at file /Users/bstansberry/dev/wildfly/wildfly-core/testsuite/manualmode/target/wildfly-core/standalone/configuration/standalone-cli.xml as there is an existing non-empty configuration there
> at org.jboss.as.controller.persistence.ConfigurationFile.getBootFile(ConfigurationFile.java:242)
> at org.jboss.as.controller.persistence.BackupXmlConfigurationPersister.<init>(BackupXmlConfigurationPersister.java:70)
> at org.jboss.as.server.Bootstrap$Configuration$1.createConfigurationPersister(Bootstrap.java:178)
> at org.jboss.as.server.ServerService.start(ServerService.java:241)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> ... 3 more
> 2015-04-20 11:27:44,031 INFO [org.jboss.modules] (main) JBoss Modules version 1.4.2.Final
> 2015-04-20 11:27:44,032 ERROR [org.jboss.msc] (main) MSC000010: Failed to register MBean with MBeanServer: javax.management.InstanceAlreadyExistsException: jboss.msc:type=container,name=jboss-as
> at com.sun.jmx.mbeanserver.Repository.addMBean(Repository.java:437)
> at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerWithRepository(DefaultMBeanServerInterceptor.java:1898)
> at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerDynamicMBean(DefaultMBeanServerInterceptor.java:966)
> at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.java:900)
> at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:324)
> at com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:522)
> at org.jboss.msc.service.ServiceContainerImpl.<init>(ServiceContainerImpl.java:372)
> at org.jboss.msc.service.ServiceContainer$Factory.create(ServiceContainer.java:266)
> at org.jboss.as.server.BootstrapImpl$ShutdownHook.register(BootstrapImpl.java:198)
> at org.jboss.as.server.BootstrapImpl$ShutdownHook.access$100(BootstrapImpl.java:188)
> at org.jboss.as.server.BootstrapImpl.<init>(BootstrapImpl.java:62)
> at org.jboss.as.server.Bootstrap$Factory.newInstance(Bootstrap.java:243)
> at org.wildfly.core.embedded.EmbeddedStandAloneServerFactory$StandaloneServerImpl.start(EmbeddedStandAloneServerFactory.java:280)
> at sun.reflect.GeneratedMethodAccessor11.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.wildfly.core.embedded.StandaloneServerIndirection.invokeOnServer(StandaloneServerIndirection.java:70)
> at org.wildfly.core.embedded.StandaloneServerIndirection.start(StandaloneServerIndirection.java:55)
> at org.jboss.as.cli.embedded.EmbedServerHandler.doHandle(EmbedServerHandler.java:201)
> at org.jboss.as.cli.handlers.CommandHandlerWithHelp.handle(CommandHandlerWithHelp.java:88)
> at org.jboss.as.cli.impl.CommandContextImpl.handle(CommandContextImpl.java:676)
> at org.jboss.as.test.integration.management.util.CLIWrapper.sendLine(CLIWrapper.java:163)
> at org.jboss.as.test.integration.management.util.CLIWrapper.sendLine(CLIWrapper.java:177)
> at org.jboss.as.test.manualmode.management.cli.CLIEmbedServerTestCase.stdoutTest(CLIEmbedServerTestCase.java:219)
> at org.jboss.as.test.manualmode.management.cli.CLIEmbedServerTestCase.testStdOutEcho(CLIEmbedServerTestCase.java:199)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
11 years
[JBoss JIRA] (WFLY-1598) Out of the box SSL - or shortly after.
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-1598?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse updated WFLY-1598:
-----------------------------------
Fix Version/s: 10.0.0.Alpha1
(was: 9.0.0.CR1)
> Out of the box SSL - or shortly after.
> --------------------------------------
>
> Key: WFLY-1598
> URL: https://issues.jboss.org/browse/WFLY-1598
> Project: WildFly
> Issue Type: Sub-task
> Components: Domain Management, Security
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Priority: Critical
> Labels: management_security,, management_sso
> Fix For: 10.0.0.Alpha1
>
>
> There are various reasons that we do not support SSL/TLS out of the box e.g.
> - If we ship a default keystore then everyone has access to the private key.
> - Generating one on first boot we do not have sufficient information to generate it correctly, also the performance overhead.
> This issue is to explorer other options to encourage their use and make it easier to configure.
> As an example could the admin console detect a non encrypted connection and have an box that encourages the config along with a wizard like workflow to get it set up?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
11 years
[JBoss JIRA] (WFLY-4304) Servlet authentication kicked off when *not* a part of any security-constraint
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-4304?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse updated WFLY-4304:
-----------------------------------
Fix Version/s: 10.0.0.Alpha1
(was: 9.0.0.CR1)
> Servlet authentication kicked off when *not* a part of any security-constraint
> ------------------------------------------------------------------------------
>
> Key: WFLY-4304
> URL: https://issues.jboss.org/browse/WFLY-4304
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 8.2.0.Final
> Reporter: Brett Meyer
> Assignee: Darran Lofthouse
> Fix For: 10.0.0.Alpha1
>
>
> Artificer runs on Wildfly 8.2 and uses Keycloak for auth. If our WAR contains a servlet that is *not* protected by a security-constraint in web.xml, Wildfly still attempts to authenticate the call (using Wireshark, I see the GET/POST get funneled through the Keycloak realm redirection) if basic auth credentials are in the header. In a keycloak-dev thread this past Dec., [~bill.burke] suggested this was most likely an issue within Wildfly auth itself.
> A credentialed call on an un-protected servlet does sound like an edge case. However, this came up possibly due to a secondary symptom:
> If I protect the servlet in web.xml, the call's Authorization header is stripped. I'm not currently able to figure out exactly where that's occurring...
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
11 years
[JBoss JIRA] (WFLY-466) Detect JBossWS Configuration for @PermitAll endpoints within Undertow subsystem.
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-466?page=com.atlassian.jira.plugin.s... ]
Darran Lofthouse updated WFLY-466:
----------------------------------
Fix Version/s: 10.0.0.Alpha1
(was: 9.0.0.CR1)
> Detect JBossWS Configuration for @PermitAll endpoints within Undertow subsystem.
> --------------------------------------------------------------------------------
>
> Key: WFLY-466
> URL: https://issues.jboss.org/browse/WFLY-466
> Project: WildFly
> Issue Type: Task
> Components: Web (Undertow)
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Fix For: 10.0.0.Alpha1
>
>
> UNDERTOW-38 has added the possibility of deploying web applications where authentication is mandated but no authorization checks are performed - this is required for integration use cases such as EJB endpoints where authorization checks are being left to the EJB container.
> This task is to update the Undertow susbsystem to detect this scenario and enable the new mode for UNDERTOW-38.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
11 years
[JBoss JIRA] (WFLY-442) Review of AccessController and PrivilegedAction use across AS7
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-442?page=com.atlassian.jira.plugin.s... ]
Darran Lofthouse updated WFLY-442:
----------------------------------
Fix Version/s: 10.0.0.Alpha1
(was: 9.0.0.CR1)
> Review of AccessController and PrivilegedAction use across AS7
> --------------------------------------------------------------
>
> Key: WFLY-442
> URL: https://issues.jboss.org/browse/WFLY-442
> Project: WildFly
> Issue Type: Task
> Components: Security
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Labels: investigation_required
> Fix For: 10.0.0.Alpha1
>
>
> The following needs reviewing across AS7: -
> - On demand instantiation of PrivilegedActions where singletons would suffice (Consider frequency of calls, gc may be preferable).
> - Use of AccessController even though there is no SecurityManager set.
> - Code duplication, in every case I have seen so far the code is the same regardless of if PRIVILEGED or NON_PRIVILEGED
> - Utility methods with visibility too high.
> - In depth review of the other methods, i.e. if the first thing a public method does is set the class loader based on a parameter passed in it could be used badly - it may even be a justification for that method to NOT use a PrivilegedAction.
> - Code that requires to be executed using a PrivilegedAction should also be double checked that it is not doing too much as the identity of the caller.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
11 years
[JBoss JIRA] (WFLY-1136) Common mechanism for all secure socket definitions
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-1136?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse updated WFLY-1136:
-----------------------------------
Fix Version/s: 10.0.0.Alpha1
(was: 9.0.0.CR1)
> Common mechanism for all secure socket definitions
> --------------------------------------------------
>
> Key: WFLY-1136
> URL: https://issues.jboss.org/browse/WFLY-1136
> Project: WildFly
> Issue Type: Sub-task
> Components: Domain Management, Security
> Reporter: Brian Stansberry
> Assignee: Darran Lofthouse
> Fix For: 10.0.0.Alpha1
>
>
> This JIRA is based on feedback we received after the Andiamo BOF at JBoss World 2010:
> >> The JAASSecurityDomain in my opinion should
> >> handle all secure socket definitions. Mod-cluster currently does
> >> not support JAASSecurityDomains.
> I won't comment either way on whether JAASSecurityDomain is how we'll do this, but I definitely agree that a common mechanism should be used for all secure socket definitions.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
11 years
[JBoss JIRA] (WFLY-3224) SSL The Last Round
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-3224?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse updated WFLY-3224:
-----------------------------------
Fix Version/s: 10.0.0.Alpha1
(was: 9.0.0.CR1)
> SSL The Last Round
> ------------------
>
> Key: WFLY-3224
> URL: https://issues.jboss.org/browse/WFLY-3224
> Project: WildFly
> Issue Type: Enhancement
> Components: Domain Management, Security
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Fix For: 10.0.0.Alpha1
>
>
> I could probably list most components in the components box, anyway this is a top level task to contain all of the SSL enhancements required so that they can be addressed once and for all.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
11 years