August 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-13706) Support a Galleon feature pack to install Keycloak adapters

by Darran Lofthouse (Jira)

[ https://issues.redhat.com/browse/WFLY-13706?page=com.atlassian.jira.plugi... ] Darran Lofthouse updated WFLY-13706: ------------------------------------ Summary: Support a Galleon feature pack to install Keycloak adapters (was: Support for adding a Keycloak feature pack with bootable jar for client side adapters) > Support a Galleon feature pack to install Keycloak adapters > ----------------------------------------------------------- > > Key: WFLY-13706 > URL: https://issues.redhat.com/browse/WFLY-13706 > Project: WildFly > Issue Type: Feature Request > Components: Documentation, Security, Test Suite > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Major > Fix For: 21.0.0.Beta1 > > > In conjunction with the bootable jar support currently being developed this feature request is to cover support for Keycloak client side adapter installation integrated with the Elytron security subsystem. > The main feature pack is anticipated to be delivered by the Keycloak project, however as this is specifically for use with WildFly we likely need WildFly documentation and possibly test cases so this Jira issue to to cover tasks required within WildFly. > -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-5079) Adjust management layers to be secured by Elytron or legacy security only

by Jean Francois Denise (Jira)

[ https://issues.redhat.com/browse/WFCORE-5079?page=com.atlassian.jira.plug... ] Jean Francois Denise commented on WFCORE-5079: ---------------------------------------------- Yes, I was CLI focused. > Adjust management layers to be secured by Elytron or legacy security only > ------------------------------------------------------------------------- > > Key: WFCORE-5079 > URL: https://issues.redhat.com/browse/WFCORE-5079 > Project: WildFly Core > Issue Type: Task > Components: Build System, Management > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Major > Fix For: 13.0.0.Beta5, 13.0.0.Final > > > At the moment it is only in the documentation that it is unsecured, a list of layers could be created similar to: > {code:xml} > <configs> > <config> > <name>standalone.xml</name> > <model>standalone</model> > <layers> > <layer>management</layer> > <layer>remoting</layer> > <layer>elytron</layer> > <layer>web-server</layer> > </layers> > </config> > {code} > From a code review of a snippet like this unless the documentation is cross referenced nothing looks out of place, if instead management was renamed unsecured-management it would be obvious in a review. > The following gist diff show the effect each of the three management layers presently has on the configuration. > * management - https://gist.github.com/darranl/e9f1c5a943684ce124c35638e376644f/revision... > * secure-management - https://gist.github.com/darranl/e9f1c5a943684ce124c35638e376644f/revision... > * legacy-management - https://gist.github.com/darranl/e9f1c5a943684ce124c35638e376644f/revision... -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-5079) Adjust management layers to be secured by Elytron or legacy security only

by Darran Lofthouse (Jira)

[ https://issues.redhat.com/browse/WFCORE-5079?page=com.atlassian.jira.plug... ] Darran Lofthouse commented on WFCORE-5079: ------------------------------------------ core-tools as a layer is usable without the management interfaces, the motivation to add the core-tools layer could be to be able to use either add-user or elytron-tool - both of which only operate on the local filesystem. If the main issue here is executing the CLI then there should be no problem with the management interfaces being secured as we already support local authentication for the CLI to be able to authenticate against the local server. > Adjust management layers to be secured by Elytron or legacy security only > ------------------------------------------------------------------------- > > Key: WFCORE-5079 > URL: https://issues.redhat.com/browse/WFCORE-5079 > Project: WildFly Core > Issue Type: Task > Components: Build System, Management > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Major > Fix For: 13.0.0.Beta5, 13.0.0.Final > > > At the moment it is only in the documentation that it is unsecured, a list of layers could be created similar to: > {code:xml} > <configs> > <config> > <name>standalone.xml</name> > <model>standalone</model> > <layers> > <layer>management</layer> > <layer>remoting</layer> > <layer>elytron</layer> > <layer>web-server</layer> > </layers> > </config> > {code} > From a code review of a snippet like this unless the documentation is cross referenced nothing looks out of place, if instead management was renamed unsecured-management it would be obvious in a review. > The following gist diff show the effect each of the three management layers presently has on the configuration. > * management - https://gist.github.com/darranl/e9f1c5a943684ce124c35638e376644f/revision... > * secure-management - https://gist.github.com/darranl/e9f1c5a943684ce124c35638e376644f/revision... > * legacy-management - https://gist.github.com/darranl/e9f1c5a943684ce124c35638e376644f/revision... -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-5079) Adjust management layers to be secured by Elytron or legacy security only

by Jean Francois Denise (Jira)

[ https://issues.redhat.com/browse/WFCORE-5079?page=com.atlassian.jira.plug... ] Jean Francois Denise commented on WFCORE-5079: ---------------------------------------------- Having core-tools to depend on management makes sense to me, core-tools is not usable without management. If we remove management dependency from core-tools, we would need to enforce core-tools+management layers in S2I for CLI scripts to be executed during server launch. User shouldn't have to provision explicitly management for our internal logic to properly operate. > Adjust management layers to be secured by Elytron or legacy security only > ------------------------------------------------------------------------- > > Key: WFCORE-5079 > URL: https://issues.redhat.com/browse/WFCORE-5079 > Project: WildFly Core > Issue Type: Task > Components: Build System, Management > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Major > Fix For: 13.0.0.Beta5, 13.0.0.Final > > > At the moment it is only in the documentation that it is unsecured, a list of layers could be created similar to: > {code:xml} > <configs> > <config> > <name>standalone.xml</name> > <model>standalone</model> > <layers> > <layer>management</layer> > <layer>remoting</layer> > <layer>elytron</layer> > <layer>web-server</layer> > </layers> > </config> > {code} > From a code review of a snippet like this unless the documentation is cross referenced nothing looks out of place, if instead management was renamed unsecured-management it would be obvious in a review. > The following gist diff show the effect each of the three management layers presently has on the configuration. > * management - https://gist.github.com/darranl/e9f1c5a943684ce124c35638e376644f/revision... > * secure-management - https://gist.github.com/darranl/e9f1c5a943684ce124c35638e376644f/revision... > * legacy-management - https://gist.github.com/darranl/e9f1c5a943684ce124c35638e376644f/revision... -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-5079) Adjust management layers to be secured by Elytron or legacy security only

by Darran Lofthouse (Jira)

[ https://issues.redhat.com/browse/WFCORE-5079?page=com.atlassian.jira.plug... ] Darran Lofthouse commented on WFCORE-5079: ------------------------------------------ [~jdenise] Overall we need to be making sure the management interfaces we pull in are secured, we should not be providing distributions with these unsecured. The provided tooling can already make use of the local authentication mechanism. Elytron is the security framework of the whole application server, all layers will being it's modules in anyway so we are only talking about the subsystem. In relation to the subsystem I do believe that needs breaking into some smaller layers. elytron-minimal, elytron-common, elytron-applications, elytron-management with the existing elytron layer depending on all of these. The management layer will then be adjusted to depend on the elytron-management-layer whilst most other layers that presently depend on elytron can instead depend on elytron-applications. I will be starting a separate thread on that one later. The alternative follow up is adjust core tools to bring in tools ONLY - i.e. don't pull in the management layer > Adjust management layers to be secured by Elytron or legacy security only > ------------------------------------------------------------------------- > > Key: WFCORE-5079 > URL: https://issues.redhat.com/browse/WFCORE-5079 > Project: WildFly Core > Issue Type: Task > Components: Build System, Management > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Major > Fix For: 13.0.0.Beta5, 13.0.0.Final > > > At the moment it is only in the documentation that it is unsecured, a list of layers could be created similar to: > {code:xml} > <configs> > <config> > <name>standalone.xml</name> > <model>standalone</model> > <layers> > <layer>management</layer> > <layer>remoting</layer> > <layer>elytron</layer> > <layer>web-server</layer> > </layers> > </config> > {code} > From a code review of a snippet like this unless the documentation is cross referenced nothing looks out of place, if instead management was renamed unsecured-management it would be obvious in a review. > The following gist diff show the effect each of the three management layers presently has on the configuration. > * management - https://gist.github.com/darranl/e9f1c5a943684ce124c35638e376644f/revision... > * secure-management - https://gist.github.com/darranl/e9f1c5a943684ce124c35638e376644f/revision... > * legacy-management - https://gist.github.com/darranl/e9f1c5a943684ce124c35638e376644f/revision... -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13789) SingletonDeploymentDescriptorTestCase fails intermittently

by Paul Ferraro (Jira)

Paul Ferraro created WFLY-13789: ----------------------------------- Summary: SingletonDeploymentDescriptorTestCase fails intermittently Key: WFLY-13789 URL: https://issues.redhat.com/browse/WFLY-13789 Project: WildFly Issue Type: Bug Components: Clustering Affects Versions: 20.0.1.Final Reporter: Paul Ferraro Assignee: Paul Ferraro e.g. [https://ci.wildfly.org/viewLog.html?buildId=218321&buildTypeId=WF_PullReq...] -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13780) Initial transformation-based tech preview EE 9 variant of WildFly

by Brian Stansberry (Jira)

[ https://issues.redhat.com/browse/WFLY-13780?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFLY-13780: ------------------------------------ Labels: EE9 (was: ) > Initial transformation-based tech preview EE 9 variant of WildFly > ----------------------------------------------------------------- > > Key: WFLY-13780 > URL: https://issues.redhat.com/browse/WFLY-13780 > Project: WildFly > Issue Type: Feature Request > Components: Build System, EE, Server > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Priority: Major > Labels: EE9 > > Produce an initial EE 9 variant of WildFly as described in https://wildfly.org/news/2020/06/23/WildFly-and-Jakarta-EE-9/ and https://lists.jboss.org/archives/list/wildfly-dev@lists.jboss.org/thread/... > This would be intended to be a milestone type release, not expected to pass the EE 9 TCK and likely not passing significant parts of the WildFly testsuite. The basic goal is to provide something to the community to look at and to surface technical issues. > Many dependencies used by this initial version may not be Final releases of the respective components. > Basic goals: > 1) Produce an EE 9 variant of the wildfly-ee feature pack. > 2) Galleon tooling to produce that feature pack and to provision a server from it that, at provisioning time, transforms any EE 8 (javax.* namespace) artifacts to EE 9 (jakarta.*). > 3) Produce a fat server dist from that feature pack. > 4) Server should be able to transform EE 8 managed deployments to EE 9 when the management layer accepts the deployment content. > Nice-to-have goals: > 1) A variant of the full 'wildfly' feature pack (which brings various MP specs) that depends on the EE 9 wildfly-ee one. > 2) Dist based on that. > Non-goals: > 1) Thin server distributions. > 2) Support for supplemental things like legacy Hibernate versions or JSF integrations beyond the default mojarra. > 3) Domain mode support for legacy AS 7 extensions that were replaced in WildFly 8. > 4) Support for the legacy security subsystem, picketlink extensions, or agroal. > Other technical points: > The default messaging configuration likely will not be for an embedded broker. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13788) Provide an Externalizer for SessionContextImpl

by Brian Stansberry (Jira)

Brian Stansberry created WFLY-13788: --------------------------------------- Summary: Provide an Externalizer for SessionContextImpl Key: WFLY-13788 URL: https://issues.redhat.com/browse/WFLY-13788 Project: WildFly Issue Type: Task Components: EJB Reporter: Brian Stansberry Assignee: Brian Stansberry The SessionContextImpl class implements SessionContext, which has the 'public MessageContext getMessageContext()' method in EE 8 but not in EE 9. The 'Message Context' return type doesn't exist in our EE 9 server, which won't provide the pruned JAXRPC API. This seems to work ok for normal operation, as the method is never used. But I'm seeing failures in the clustering testsuite in cases where the SessionContextImpl is being marshalled. The default marshalling is iterating over Class.getDeclaredMethods, which then tries to load the non-existent MessageContext class which fails. Workaround to this is to register an Externalizer for this class. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13788) Provide an Externalizer for SessionContextImpl

by Brian Stansberry (Jira)

[ https://issues.redhat.com/browse/WFLY-13788?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFLY-13788: ------------------------------------ Labels: EE9 (was: ) > Provide an Externalizer for SessionContextImpl > ---------------------------------------------- > > Key: WFLY-13788 > URL: https://issues.redhat.com/browse/WFLY-13788 > Project: WildFly > Issue Type: Task > Components: EJB > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Priority: Major > Labels: EE9 > > The SessionContextImpl class implements SessionContext, which has the 'public MessageContext getMessageContext()' method in EE 8 but not in EE 9. The 'Message Context' return type doesn't exist in our EE 9 server, which won't provide the pruned JAXRPC API. > This seems to work ok for normal operation, as the method is never used. But I'm seeing failures in the clustering testsuite in cases where the SessionContextImpl is being marshalled. The default marshalling is iterating over Class.getDeclaredMethods, which then tries to load the non-existent MessageContext class which fails. > Workaround to this is to register an Externalizer for this class. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-5098) Upgrade WildFly OpenSSL to 2.0.0.Alpha1

by Farah Juma (Jira)

[ https://issues.redhat.com/browse/WFCORE-5098?page=com.atlassian.jira.plug... ] Farah Juma deleted WFCORE-5098: ------------------------------- > Upgrade WildFly OpenSSL to 2.0.0.Alpha1 > --------------------------------------- > > Key: WFCORE-5098 > URL: https://issues.redhat.com/browse/WFCORE-5098 > Project: WildFly Core > Issue Type: Component Upgrade > Components: Security > Reporter: Farah Juma > Assignee: Farah Juma > Priority: Major > -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 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 August 2020