[JBoss JIRA] (WFCORE-4482) Out of the box SSL with Wildfly Elytron
by Jeff Mesnil (Jira)
[ https://issues.redhat.com/browse/WFCORE-4482?page=com.atlassian.jira.plug... ]
Jeff Mesnil updated WFCORE-4482:
--------------------------------
Fix Version/s: 11.0.0.Beta7
(was: 11.0.0.Beta6)
> Out of the box SSL with Wildfly Elytron
> ---------------------------------------
>
> Key: WFCORE-4482
> URL: https://issues.redhat.com/browse/WFCORE-4482
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Security
> Reporter: Farah Juma
> Assignee: Farah Juma
> Priority: Major
> Labels: EAP-CD19
> Fix For: 11.0.0.Beta7
>
>
> The details of this RFE will be explored within the analysis, presently Undertow depends on a security-realm that generates a self signed cert on start up so we will require an Elytron equivalent.
> There may be opportunities to tie this in in some way with the new CA integration support but that can be explored in the analysis.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 10 months
[JBoss JIRA] (WFCORE-3376) Modules may create loggers on a deployments log context
by Jeff Mesnil (Jira)
[ https://issues.redhat.com/browse/WFCORE-3376?page=com.atlassian.jira.plug... ]
Jeff Mesnil updated WFCORE-3376:
--------------------------------
Fix Version/s: 11.0.0.Beta7
(was: 11.0.0.Beta6)
> Modules may create loggers on a deployments log context
> -------------------------------------------------------
>
> Key: WFCORE-3376
> URL: https://issues.redhat.com/browse/WFCORE-3376
> Project: WildFly Core
> Issue Type: Bug
> Components: Logging
> Reporter: James Perkins
> Assignee: James Perkins
> Priority: Critical
> Fix For: 11.0.0.Beta7
>
>
> Currently WildFly uses a {{ClassLoaderLogContextSelector}} to determine the log context to use when creating loggers. If a deployment has it's own log context, via logging-profile or per-deployment logging, and a dependency on a module, that module may create loggers on the deployments log context. This is due to the fact the the call stack is walked until it finds a log context associated with a class loader.
> What is needed is a way to short-circuit once a non-logging API class loader is found and determine if there is an associated log context with the callers class loader.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 10 months
[JBoss JIRA] (WFCORE-944) truststore path is ignored if provider is not JKS
by Jeff Mesnil (Jira)
[ https://issues.redhat.com/browse/WFCORE-944?page=com.atlassian.jira.plugi... ]
Jeff Mesnil updated WFCORE-944:
-------------------------------
Fix Version/s: 11.0.0.Beta7
(was: 11.0.0.Beta6)
> truststore path is ignored if provider is not JKS
> -------------------------------------------------
>
> Key: WFCORE-944
> URL: https://issues.redhat.com/browse/WFCORE-944
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Reporter: Arto Huusko
> Priority: Major
> Fix For: 11.0.0.Beta7
>
>
> truststore configuration ignores the path and relative-to parameters if the truststore provider is anything else than JKS.
> This works as documented, but it is not correct. There can be and are truststore implementations that need to load parameters or whatever data from a file, and the current implementation prevents these truststore providers from working.
> We have a custom truststore that is loaded from database, and database access parameters are read from a properties file. When trying to use this with Wildfly 9, the keystore engineLoad parameter is passed in as null, even though path and relative-to are configured.
> Even standard java supports PKCS12 truststores, where the same problem would occur.
> So I would suggest that
> - if provider is JKS, path is mandatory
> - if provider is not JKS, but path is specified, it is passed to the provider
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 10 months
[JBoss JIRA] (WFCORE-4485) Support for multiple security realms - Distributed Identities
by Jeff Mesnil (Jira)
[ https://issues.redhat.com/browse/WFCORE-4485?page=com.atlassian.jira.plug... ]
Jeff Mesnil updated WFCORE-4485:
--------------------------------
Fix Version/s: 11.0.0.Beta7
(was: 11.0.0.Beta6)
> Support for multiple security realms - Distributed Identities
> -------------------------------------------------------------
>
> Key: WFCORE-4485
> URL: https://issues.redhat.com/browse/WFCORE-4485
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Security
> Reporter: Farah Juma
> Priority: Major
> Labels: CD17-Deferred, EAP-CD19, Previous_RFE
> Fix For: 11.0.0.Beta7
>
>
> By stacking LoginModules it was possible using PicketBox to attempt to authenticate using one remote store and if that failed try the next store in the list.
> This RFE is to consider the use case where identities could be located across multiple stores and how they are aggregated together.
> Additionally this use case should consider how the authorization information could be loaded from multiple sources and merged.
> This RFE is not about fail over in the event of a realm being unavailable although it may be related.
> This RFE is created as a result of comparing the differences between the PicketBox JAAS architecture and the Elytron architecture so I would not recommend this proceeds without some real world use cases identified.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 10 months
[JBoss JIRA] (WFCORE-4791) HttpManagementConstantHeadersTestCase causes tests failures
by Jeff Mesnil (Jira)
[ https://issues.redhat.com/browse/WFCORE-4791?page=com.atlassian.jira.plug... ]
Jeff Mesnil updated WFCORE-4791:
--------------------------------
Fix Version/s: 11.0.0.Beta7
(was: 11.0.0.Beta6)
> HttpManagementConstantHeadersTestCase causes tests failures
> -----------------------------------------------------------
>
> Key: WFCORE-4791
> URL: https://issues.redhat.com/browse/WFCORE-4791
> Project: WildFly Core
> Issue Type: Bug
> Components: Test Suite
> Reporter: Richard Opalka
> Assignee: Tomas Terem
> Priority: Major
> Fix For: 11.0.0.Beta7
>
> Attachments: testsuite.log
>
>
> Commit 68928b0b in WildFly-Core introduced new regression.
> High probably test doesn't do proper test environment clean up
> and some tests following it are thus failing. The issue isn't visible
> in our CI environment so it probably depends on actual tests ordering.
> I am able to reproduce this issue on my laptop always.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 10 months