[JBoss JIRA] (WFLY-1598) Out of the box SSL - or shortly after.
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-1598?page=com.atlassian.jira.plugin.... ]
Jason Greene updated WFLY-1598:
-------------------------------
Fix Version/s: 11.0.0.Beta1
(was: 11.0.0.Alpha1)
> 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: 11.0.0.Beta1
>
>
> 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
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (WFLY-1033) Enhance XTS AS7 configuration
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-1033?page=com.atlassian.jira.plugin.... ]
Jason Greene updated WFLY-1033:
-------------------------------
Fix Version/s: 11.0.0.Beta1
(was: 11.0.0.Alpha1)
> Enhance XTS AS7 configuration
> -----------------------------
>
> Key: WFLY-1033
> URL: https://issues.jboss.org/browse/WFLY-1033
> Project: WildFly
> Issue Type: Enhancement
> Components: XTS
> Reporter: Andrew Dinn
> Priority: Minor
> Fix For: 11.0.0.Beta1
>
>
> The current integration of XTS into AS7 as an AS7 extension allows optional configuration of the coordinator URL from the <xts/> element in the AS7 standalone configuration file. No other configuration options are currently supported.
> XTS ought to support more precise configuration. IN particular, it ought to be possible to enable or disable deployment of coordinator, participant or client services independently and also to choose whether to deploy WS-AT or WS-BA services or both. This requires selectively deploying only the required web service endpoints, selectively executing the required initialization routines and selectively loading the required high level service implementations and context factory implementations.
> The XTS implementation has already been factored so as to to support such discriminated bootstrapping. So this task only requires modifying the AS7 extension code to manage the relevant configuration information and install the relevant values into the XTS environment configuration beans before starting the XTS service.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (WFLY-4304) Servlet authentication kicked off when *not* a part of any security-constraint
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-4304?page=com.atlassian.jira.plugin.... ]
Jason Greene updated WFLY-4304:
-------------------------------
Fix Version/s: 11.0.0.Beta1
(was: 11.0.0.Alpha1)
> 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
> Components: Web (Undertow)
> Affects Versions: 8.2.0.Final
> Reporter: Brett Meyer
> Assignee: Darran Lofthouse
> Fix For: 11.0.0.Beta1
>
>
> 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
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (WFLY-2102) Improve deployment annotation parsing error message
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-2102?page=com.atlassian.jira.plugin.... ]
Jason Greene updated WFLY-2102:
-------------------------------
Fix Version/s: 11.0.0.Beta1
(was: 11.0.0.Alpha1)
> Improve deployment annotation parsing error message
> -----------------------------------------------------
>
> Key: WFLY-2102
> URL: https://issues.jboss.org/browse/WFLY-2102
> Project: WildFly
> Issue Type: Enhancement
> Components: EE
> Reporter: Brad Maxwell
> Fix For: 11.0.0.Beta1
>
> Attachments: test-WFLY-2102.jar
>
>
> Improve deployment annotation parsing error message
> Code such as this below, will error with IllegalArgumentException: Empty name segment is not allowed for env. The env is not enough information to identify what the issue is.
> @Singleton
> @Startup
> public class TestEJB {
> @Resource(name="/queue/test")
> private Queue queue;
> }
> Caused by: java.lang.IllegalArgumentException: Empty name segment is not allowed for env
> at org.jboss.msc.service.ServiceName.of(ServiceName.java:85) [jboss-msc-1.0.4.GA-redhat-1.jar:1.0.4.GA-redhat-1]
> at org.jboss.msc.service.ServiceName.append(ServiceName.java:112) [jboss-msc-1.0.4.GA-redhat-1.jar:1.0.4.GA-redhat-1]
> at org.jboss.as.naming.deployment.ContextNames.buildServiceName(ContextNames.java:183)
> at org.jboss.as.naming.deployment.ContextNames$BindInfo.<init>(ContextNames.java:195)
> at org.jboss.as.naming.deployment.ContextNames$BindInfo.<init>(ContextNames.java:186)
> at org.jboss.as.naming.deployment.ContextNames.bindInfoFor(ContextNames.java:141)
> at org.jboss.as.ee.component.OptionalLookupInjectionSource.getResourceValue(OptionalLookupInjectionSource.java:84)
> at org.jboss.as.ee.component.ComponentDescription$InjectedConfigurator.configureDependency(ComponentDescription.java:1019)
> at org.jboss.as.ee.component.ComponentDescription$InjectedConfigurator.configureDependency(ComponentDescription.java:998)
> at org.jboss.as.ee.component.deployers.ComponentInstallProcessor.deployComponent(ComponentInstallProcessor.java:138)
> at org.jboss.as.ee.component.deployers.ComponentInstallProcessor.deploy(ComponentInstallProcessor.java:95)
> ... 6 more
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (WFLY-5551) Formalize ejb clustering modules into a proper subsystem
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-5551?page=com.atlassian.jira.plugin.... ]
Jason Greene updated WFLY-5551:
-------------------------------
Fix Version/s: 11.0.0.Beta1
(was: 11.0.0.Alpha1)
> Formalize ejb clustering modules into a proper subsystem
> --------------------------------------------------------
>
> Key: WFLY-5551
> URL: https://issues.jboss.org/browse/WFLY-5551
> Project: WildFly
> Issue Type: Enhancement
> Components: Clustering
> Affects Versions: 10.0.0.CR3
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Fix For: 11.0.0.Beta1
>
>
> Currently, the coupling between the ejb3 subsystem and the modules required for the distributed cache is very loose.
> Consequently, misconfiguration (e.g. a missing "ejb" cache-container) can prevent deployment from succeeding without an adequate explanation.
> The subsystem would define the requisite cache-container, exposed as a capability.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month