[JBoss JIRA] (WFCORE-5033) Move org.wildfly.security:wildfly-elytron-jacc into it's own module
by James Perkins (Jira)
[ https://issues.redhat.com/browse/WFCORE-5033?page=com.atlassian.jira.plug... ]
James Perkins updated WFCORE-5033:
----------------------------------
Fix Version/s: 13.0.0.Beta6
(was: 13.0.0.Beta5)
> Move org.wildfly.security:wildfly-elytron-jacc into it's own module
> -------------------------------------------------------------------
>
> Key: WFCORE-5033
> URL: https://issues.redhat.com/browse/WFCORE-5033
> Project: WildFly Core
> Issue Type: Task
> Components: Security
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Priority: Major
> Fix For: 13.0.0.Beta6
>
>
> Long term it will be desirable for JACC to be within it's own subsystem so it's inclusion can be controlled using layers, however there may be an intermediate step where we split JACC out from the Elytron project so will want to bring it in ideally in it's own module.
> The classes within this module have never been public API so we are free to refactor as needed.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 11 months
[JBoss JIRA] (WFCORE-5078) remoting layer defines no dependencies
by James Perkins (Jira)
[ https://issues.redhat.com/browse/WFCORE-5078?page=com.atlassian.jira.plug... ]
James Perkins updated WFCORE-5078:
----------------------------------
Fix Version/s: 13.0.0.Beta6
(was: 13.0.0.Beta5)
> remoting layer defines no dependencies
> --------------------------------------
>
> Key: WFCORE-5078
> URL: https://issues.redhat.com/browse/WFCORE-5078
> Project: WildFly Core
> Issue Type: Bug
> Components: Build System, Remoting
> Affects Versions: 13.0.0.Beta2
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Priority: Major
> Fix For: 13.0.0.Beta6
>
>
> The remoting layer depends upon legacy security realms but this dependency is not defined.
> The layer named "remoting" should be updated to reference an elytron sasl-authentication-factory and the layer should depend upon the elytron layer.
> There should be a second layer "legacy-remoting" which references the ApplicationRealm security realm and also this layer should have a dependency on the layer "application-security-realm".
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 11 months
[JBoss JIRA] (WFLY-13666) Loss of Servlet Context Data when request canceled.
by Cody Lerum (Jira)
[ https://issues.redhat.com/browse/WFLY-13666?page=com.atlassian.jira.plugi... ]
Cody Lerum commented on WFLY-13666:
-----------------------------------
[~flavia.rainone] Checking back in on this one to see if there is anything else I can do beyond the reproducer project to help get this resolved.
> Loss of Servlet Context Data when request canceled.
> ---------------------------------------------------
>
> Key: WFLY-13666
> URL: https://issues.redhat.com/browse/WFLY-13666
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 20.0.1.Final
> Reporter: Cody Lerum
> Assignee: Flavia Rainone
> Priority: Major
>
> NPE occasionally raised in Wildfly 20.0.1 when the response a view is requested repeatedly from the same tab by rapidly double clicking.
> This issue was found while trying to find a reproducer to WFLY-13662 so which could also be failing if some of the request context data is being lost.
> {code:java}
> 14:49:14,782 ERROR [io.undertow.request] (default task-8) UT005023: Exception handling request to /demo/list.xhtml: java.lang.NullPointerException14:49:14,782 ERROR [io.undertow.request] (default task-8) UT005023: Exception handling request to /demo/list.xhtml: java.lang.NullPointerException at deployment.demo.war//org.ocpsoft.rewrite.servlet.RewriteFilter.getFilterCount(RewriteFilter.java:316) at deployment.demo.war//org.ocpsoft.rewrite.servlet.RewriteFilter.doFilter(RewriteFilter.java:208) at io.undertow.servlet@2.1.3.Final//io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61) at io.undertow.servlet@2.1.3.Final//io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) at deployment.demo.war//demo.DemoFilter.doFilter(DemoFilter.java:30) at javax.servlet.api@2.0.0.Final//javax.servlet.http.HttpFilter.doFilter(HttpFilter.java:97) at io.undertow.servlet@2.1.3.Final//io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61) at io.undertow.servlet@2.1.3.Final//io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) at io.undertow.servlet@2.1.3.Final//io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84) at io.undertow.servlet@2.1.3.Final//io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) at io.undertow.servlet@2.1.3.Final//io.undertow.servlet.handlers.ServletChain$1.handleRequest(ServletChain.java:68) at io.undertow.servlet@2.1.3.Final//io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) at org.wildfly.extension.undertow@20.0.1.Final//org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) at io.undertow.core@2.1.3.Final//io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.servlet@2.1.3.Final//io.undertow.servlet.handlers.RedirectDirHandler.handleRequest(RedirectDirHandler.java:68) at io.undertow.servlet@2.1.3.Final//io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:132) at io.undertow.servlet@2.1.3.Final//io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) at io.undertow.core@2.1.3.Final//io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.core@2.1.3.Final//io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) at io.undertow.servlet@2.1.3.Final//io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) at io.undertow.core@2.1.3.Final//io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) at io.undertow.servlet@2.1.3.Final//io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) at io.undertow.core@2.1.3.Final//io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) at io.undertow.core@2.1.3.Final//io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) at io.undertow.core@2.1.3.Final//io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at org.wildfly.extension.undertow@20.0.1.Final//org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) at io.undertow.core@2.1.3.Final//io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at org.wildfly.extension.undertow@20.0.1.Final//org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68) at io.undertow.core@2.1.3.Final//io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.servlet@2.1.3.Final//io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:269) at io.undertow.servlet@2.1.3.Final//io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:78) at io.undertow.servlet@2.1.3.Final//io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:133) at io.undertow.servlet@2.1.3.Final//io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:130) at io.undertow.servlet@2.1.3.Final//io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48) at io.undertow.servlet@2.1.3.Final//io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43) at org.wildfly.extension.undertow@20.0.1.Final//org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105) at org.wildfly.extension.undertow@20.0.1.Final//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1530) at org.wildfly.extension.undertow@20.0.1.Final//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1530) at org.wildfly.extension.undertow@20.0.1.Final//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1530) at org.wildfly.extension.undertow@20.0.1.Final//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1530) at io.undertow.servlet@2.1.3.Final//io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:249) at io.undertow.servlet@2.1.3.Final//io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:78) at io.undertow.servlet@2.1.3.Final//io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:99) at io.undertow.core@2.1.3.Final//io.undertow.server.Connectors.executeRootHandler(Connectors.java:370) at io.undertow.core@2.1.3.Final//io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:830) at org.jboss.threads@2.3.3.Final//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35) at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982) at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486) at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377) at java.base/java.lang.Thread.run(Thread.java:832) {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 11 months
[JBoss JIRA] (WFLY-13782) Add the ability to make use of an automatically generated self-signed certificate with Elytron
by Farah Juma (Jira)
[ https://issues.redhat.com/browse/WFLY-13782?page=com.atlassian.jira.plugi... ]
Farah Juma moved WFCORE-5096 to WFLY-13782:
-------------------------------------------
Project: WildFly (was: WildFly Core)
Key: WFLY-13782 (was: WFCORE-5096)
Component/s: Security
(was: Security)
> Add the ability to make use of an automatically generated self-signed certificate with Elytron
> ----------------------------------------------------------------------------------------------
>
> Key: WFLY-13782
> URL: https://issues.redhat.com/browse/WFLY-13782
> Project: WildFly
> Issue Type: Feature Request
> Components: Security
> Reporter: Farah Juma
> Assignee: Farah Juma
> Priority: Major
>
> WFCORE-1576 added the ability to lazily generate a self-signed certificate on first use for a specified host name when using legacy security. This RFE is to provide similar functionality when Elytron is in use. Like with legacy security, it will be important to log a warning message so the user knows that a self-signed certificate is being used and to indicate that this certificate should not be used in a production environment.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 11 months
[JBoss JIRA] (WFCORE-5096) Add the ability to make use of an automatically generated self-signed certificate with Elytron
by Farah Juma (Jira)
Farah Juma created WFCORE-5096:
----------------------------------
Summary: Add the ability to make use of an automatically generated self-signed certificate with Elytron
Key: WFCORE-5096
URL: https://issues.redhat.com/browse/WFCORE-5096
Project: WildFly Core
Issue Type: Feature Request
Components: Security
Reporter: Farah Juma
Assignee: Farah Juma
WFCORE-1576 added the ability to lazily generate a self-signed certificate on first use for a specified host name when using legacy security. This RFE is to provide similar functionality when Elytron is in use. Like with legacy security, it will be important to log a warning message so the user knows that a self-signed certificate is being used and to indicate that this certificate should not be used in a production environment.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 11 months
[JBoss JIRA] (WFCORE-5095) Add the ability to make use of an automatically generated self-signed certificate with Elytron
by Farah Juma (Jira)
[ https://issues.redhat.com/browse/WFCORE-5095?page=com.atlassian.jira.plug... ]
Farah Juma updated WFCORE-5095:
-------------------------------
Labels: (was: Active-Development)
> Add the ability to make use of an automatically generated self-signed certificate with Elytron
> ----------------------------------------------------------------------------------------------
>
> Key: WFCORE-5095
> URL: https://issues.redhat.com/browse/WFCORE-5095
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Security
> Reporter: Farah Juma
> Assignee: Farah Juma
> Priority: Major
>
> WFCORE-1576 added the ability to lazily generate a self-signed certificate on first use for a specified host name when using legacy security. This RFE is to provide similar functionality when Elytron is in use. Like with legacy security, it will be important to log a warning message so the user knows that a self-signed certificate is being used and to indicate that this certificate should not be used in a production environment.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 11 months
[JBoss JIRA] (WFCORE-5095) Add the ability to make use of an automatically generated self-signed certificate with Elytron
by Farah Juma (Jira)
[ https://issues.redhat.com/browse/WFCORE-5095?page=com.atlassian.jira.plug... ]
Farah Juma updated WFCORE-5095:
-------------------------------
Description: WFCORE-1576 added the ability to lazily generate a self-signed certificate on first use for a specified host name when using legacy security. This RFE is to provide similar functionality when Elytron is in use. Like with legacy security, it will be important to log a warning message so the user knows that a self-signed certificate is being used and to indicate that this certificate should not be used in a production environment. (was: EAP7-584 added the ability to lazily generate a self-signed certificate on first use for a specified host name when using legacy security. This RFE is to provide similar functionality when Elytron is in use. Like with legacy security, it will be important to log a warning message so the user knows that a self-signed certificate is being used and to indicate that this certificate should not be used in a production environment.)
> Add the ability to make use of an automatically generated self-signed certificate with Elytron
> ----------------------------------------------------------------------------------------------
>
> Key: WFCORE-5095
> URL: https://issues.redhat.com/browse/WFCORE-5095
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Security
> Reporter: Farah Juma
> Assignee: Farah Juma
> Priority: Major
> Labels: Active-Development
>
> WFCORE-1576 added the ability to lazily generate a self-signed certificate on first use for a specified host name when using legacy security. This RFE is to provide similar functionality when Elytron is in use. Like with legacy security, it will be important to log a warning message so the user knows that a self-signed certificate is being used and to indicate that this certificate should not be used in a production environment.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 11 months
[JBoss JIRA] (WFCORE-5095) Add the ability to make use of an automatically generated self-signed certificate with Elytron
by Farah Juma (Jira)
[ https://issues.redhat.com/browse/WFCORE-5095?page=com.atlassian.jira.plug... ]
Farah Juma moved EAP7-1546 to WFCORE-5095:
------------------------------------------
Project: WildFly Core (was: JBoss EAP Planning for version 7 and above)
Key: WFCORE-5095 (was: EAP7-1546)
Issue Type: Feature Request (was: Requirement)
Workflow: GIT Pull Request workflow (was: EAP Agile Workflow 2.0)
Component/s: Security
(was: Security)
EAP PT Pre-Checked (PC): (was: TODO)
Target Release: (was: 7.4.0.GA)
EAP PT Community Docs (CD): (was: TODO)
EAP PT Product Docs (PD): (was: New)
EAP PT Test Dev (TD): (was: TODO)
EAP PT Docs Analysis (DA): (was: TODO)
EAP PT Test Plan (TP): (was: TODO)
EAP PT Analysis Document (AD): (was: TODO)
> Add the ability to make use of an automatically generated self-signed certificate with Elytron
> ----------------------------------------------------------------------------------------------
>
> Key: WFCORE-5095
> URL: https://issues.redhat.com/browse/WFCORE-5095
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Security
> Reporter: Farah Juma
> Assignee: Farah Juma
> Priority: Major
> Labels: Active-Development
>
> EAP7-584 added the ability to lazily generate a self-signed certificate on first use for a specified host name when using legacy security. This RFE is to provide similar functionality when Elytron is in use. Like with legacy security, it will be important to log a warning message so the user knows that a self-signed certificate is being used and to indicate that this certificate should not be used in a production environment.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 11 months