February 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-3832) Support hex encoding in jdbc-realm for elytron

by Jeff Mesnil (Jira)

[ https://issues.jboss.org/browse/WFCORE-3832?page=com.atlassian.jira.plugi... ] Jeff Mesnil updated WFCORE-3832: -------------------------------- Fix Version/s: 8.0.0.Beta6 (was: 8.0.0.Beta5) > Support hex encoding in jdbc-realm for elytron > ---------------------------------------------- > > Key: WFCORE-3832 > URL: https://issues.jboss.org/browse/WFCORE-3832 > Project: WildFly Core > Issue Type: Feature Request > Components: Security > Affects Versions: 5.0.0.Alpha7 > Reporter: Jan Kalina > Assignee: Darran Lofthouse > Priority: Major > Labels: elytron > Fix For: 8.0.0.Beta6 > > > Old database login-module can be configured passing the attribute {{hashEncoding}}, for example: > {code:xml} > <login-module code="Database" flag="required"> > <module-option name="dsJndiName" value="java:jboss/datasources/ExampleDS"/> > <module-option name="principalsQuery" value="SELECT password FROM User WHERE username = ?"/> > <module-option name="rolesQuery" value="SELECT role, 'Roles' FROM User WHERE username = ?"/> > <module-option name="hashAlgorithm" value="SHA-1"/> > <module-option name="hashEncoding" value="hex"/> > <module-option name="hashCharset" value="UTF-8"/> > </login-module> > {code} > Currently jdbc-realm in elytron only uses base64 encoding if hash is stored in a text column. This way the migration is more complicated cos the password hash is not valid changing from old security system to elytron. > Think also about the charset attribute. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3947) Support SSL Certificate revocation using OCSP

by Jeff Mesnil (Jira)

[ https://issues.jboss.org/browse/WFCORE-3947?page=com.atlassian.jira.plugi... ] Jeff Mesnil updated WFCORE-3947: -------------------------------- Fix Version/s: 8.0.0.Beta6 (was: 8.0.0.Beta5) > Support SSL Certificate revocation using OCSP > --------------------------------------------- > > Key: WFCORE-3947 > URL: https://issues.jboss.org/browse/WFCORE-3947 > Project: WildFly Core > Issue Type: Task > Components: Security > Affects Versions: 6.0.0.Alpha2 > Reporter: Jan Kalina > Assignee: Martin Mazanek > Priority: Critical > Fix For: 8.0.0.Beta6 > > > - Provide undertow's client certificate revocation capability when undertow is used as a load balancer using OCSP. > (CRL capability is provided in the earlier release as part of Elytron SSL Consolidation effort that this JIRA is cloned from) -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3983) Update the WildFly Elytron Subsystem to use the new MSC Service API

by Jeff Mesnil (Jira)

[ https://issues.jboss.org/browse/WFCORE-3983?page=com.atlassian.jira.plugi... ] Jeff Mesnil updated WFCORE-3983: -------------------------------- Fix Version/s: 8.0.0.Beta6 (was: 8.0.0.Beta5) > Update the WildFly Elytron Subsystem to use the new MSC Service API > ------------------------------------------------------------------- > > Key: WFCORE-3983 > URL: https://issues.jboss.org/browse/WFCORE-3983 > Project: WildFly Core > Issue Type: Task > Components: Security > Reporter: Darran Lofthouse > Priority: Major > Fix For: 8.0.0.Beta6 > > > At some point we want to consider breaking the subsystem into smaller chunks to allow a more selective subset of functionality to be selected - before we do that it would be good to clean up the general approach in the subsystem. We have trivial resources and services within the subsystem but the new MSC APIs may simpify a lot of this. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4259) Upgrade WildFly Elytron to 1.8.x

by Jeff Mesnil (Jira)

[ https://issues.jboss.org/browse/WFCORE-4259?page=com.atlassian.jira.plugi... ] Jeff Mesnil updated WFCORE-4259: -------------------------------- Fix Version/s: 8.0.0.Beta6 (was: 8.0.0.Beta5) > Upgrade WildFly Elytron to 1.8.x > -------------------------------- > > Key: WFCORE-4259 > URL: https://issues.jboss.org/browse/WFCORE-4259 > Project: WildFly Core > Issue Type: Component Upgrade > Components: Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Major > Fix For: 8.0.0.Beta6 > > -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4261) Update Maven dependencies to reference individual Elytron modules.

by Jeff Mesnil (Jira)

[ https://issues.jboss.org/browse/WFCORE-4261?page=com.atlassian.jira.plugi... ] Jeff Mesnil updated WFCORE-4261: -------------------------------- Fix Version/s: 8.0.0.Beta6 (was: 8.0.0.Beta5) > Update Maven dependencies to reference individual Elytron modules. > ------------------------------------------------------------------ > > Key: WFCORE-4261 > URL: https://issues.jboss.org/browse/WFCORE-4261 > Project: WildFly Core > Issue Type: Task > Components: Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Major > Fix For: 8.0.0.Beta6 > > > Additionally remove the root 'wildfly-elytron' dependency. > This should also review the classes the application server users as we will likely want to start considering these public API. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4282) Remove use of java.security.acl APIs in Elytron PolicyDefinitions

by Jeff Mesnil (Jira)

[ https://issues.jboss.org/browse/WFCORE-4282?page=com.atlassian.jira.plugi... ] Jeff Mesnil updated WFCORE-4282: -------------------------------- Fix Version/s: 8.0.0.Beta6 (was: 8.0.0.Beta5) > Remove use of java.security.acl APIs in Elytron PolicyDefinitions > ----------------------------------------------------------------- > > Key: WFCORE-4282 > URL: https://issues.jboss.org/browse/WFCORE-4282 > Project: WildFly Core > Issue Type: Task > Components: Security > Reporter: Darran Lofthouse > Priority: Critical > Labels: Java13 > Fix For: 8.0.0.Beta6 > > > The 'java.security.acls' packages has been deprecated and flagged for removal, this will be removed in Java 13 > https://bugs.openjdk.java.net/browse/JDK-8191138 > Within the Elytron subsystem we are presently using it within the PolicyDefinitions / Subject conversion likely to maintain compatibility with prior PicketBox implementations. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3628) Ignore unreliable KieScannerMemoryTest

by Tibor Zimányi (Jira)

Tibor Zimányi created DROOLS-3628: ------------------------------------- Summary: Ignore unreliable KieScannerMemoryTest Key: DROOLS-3628 URL: https://issues.jboss.org/browse/DROOLS-3628 Project: Drools Issue Type: Task Components: core engine Affects Versions: 7.17.0.Final Reporter: Tibor Zimányi Assignee: Tibor Zimányi We have KieScannerMemoryTest test class which should check for memory leaks. However this test class is unreliable, because it depends at the number of steps during which memory raises. However with unpredictable GC behaviour, this sometimes reports false negatives. Therefore we should @Ignore it. It could help debugging memory leaks when used locally, but in automated test runs, it should be disabled. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11535) Cluster fails to merge if instances started simultaneously

by Ian Rodgers (Jira)

[ https://issues.jboss.org/browse/WFLY-11535?page=com.atlassian.jira.plugin... ] Ian Rodgers commented on WFLY-11535: ------------------------------------ We have managed to solve the problem by downloading the JGroups jar file, which incorporates the fix to JGRP-2288 (jgroups-4.0.16.Final.jar), and incorporating it into our Docker build. > Cluster fails to merge if instances started simultaneously > ---------------------------------------------------------- > > Key: WFLY-11535 > URL: https://issues.jboss.org/browse/WFLY-11535 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 14.0.0.Final > Environment: Keycloak 4.6.0 official docker image, AWS ECS cluster > Reporter: Ian Rodgers > Assignee: Paul Ferraro > Priority: Major > Attachments: Dockerfile, docker-entrypoint.sh, entrypoint.sh, standalone-ha.xml, standalone-ha.xml > > > Our Keycloak docker cluster has four instances, clustered using Jgroups/Infinispan as per the standalone-ha.xml. If you start them all simultaneously the "Receive new cluster" logs indicate four separate clusters, each with a single member. They never get merged into the proper single cluster of four members. It seems to be the merging that has changed. The application then fails (we are not using sticky sessions, and each member is ignorant of the sessions on the other members). > We can only start the cluster by first starting one instance, then when it is running, starting the other three. The logs then indicate the creation of a single cluster which subsequent instances join. > This is consistent behaviour, and when we revert back to v.4.5.0, the issue goes away, Unfortunately we need 4.6.0 for an important fix. > On 4.5.0 we get the message "Received new, MERGED cluster view for channel ejb: MergeView::" when it detects a number of subgroups to merge. This never appears in 4.6.0. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10319) NameBinding annotations on resources are ignored in subresources

by Javier Estevez Sanchez (Jira)

[ https://issues.jboss.org/browse/WFLY-10319?page=com.atlassian.jira.plugin... ] Javier Estevez Sanchez commented on WFLY-10319: ----------------------------------------------- Ok for me. > NameBinding annotations on resources are ignored in subresources > ---------------------------------------------------------------- > > Key: WFLY-10319 > URL: https://issues.jboss.org/browse/WFLY-10319 > Project: WildFly > Issue Type: Bug > Components: REST > Affects Versions: 12.0.0.Final > Reporter: Javier Estevez Sanchez > Assignee: Alessio Soldano > Priority: Major > > The following JAX-RS resource exposes two resources via a GET operation: /demo and /demo/subresource. The first one via a sub-resource method, the latter via a sub-resource locator. Additionally, a response filter is binded to the JAX-RS resource class to modify the response. From the JAX-RS 2.0 spec, §6.5.2 Name Binding: > {quote} > Binding annotations that decorate resource classes apply to all resource methods defined in them. > {quote} > However, the binding annotation is not applying to the sub-resource locator method. This happens when the name binding annotation is on the resource class or on the sub-resource locator method. Annotating the sub-resource class or the method within works as expected, though. > Below is the code needed to reproduce this issue: > {code:java|title=The resource and subresource} > @DemoNameBinding > @Produces(MediaType.APPLICATION_JSON) > @Path("/demo") > public class DemoResource { > @GET > public String getDemoValue() { > return "A value"; > } > @Path("/subresource") > public DemoSubResource getSubResource() { > return new DemoSubResource(); > } > public class DemoSubResource { > @GET > public String getDemoValue() { > return "A value"; > } > } > } > {code} > {code:java|title=The filter} > @Provider > @DemoNameBinding > public class SomeFilter implements ContainerResponseFilter { > @Override > public void filter(ContainerRequestContext requestContext, ContainerResponseContext responseContext) { > responseContext.setEntity("A filtered value"); > } > } > {code} > {code:java|title=The binding} > @NameBinding > @Target({ElementType.TYPE, ElementType.METHOD}) > @Retention(RetentionPolicy.RUNTIME) > public @interface DemoNameBinding { > } > {code} -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10319) NameBinding annotations on resources are ignored in subresources

by Ron Sigal (Jira)

[ https://issues.jboss.org/browse/WFLY-10319?page=com.atlassian.jira.plugin... ] Ron Sigal commented on WFLY-10319: ---------------------------------- So, [~jestevezsanchez], [~mkopecky], we can close this one? > NameBinding annotations on resources are ignored in subresources > ---------------------------------------------------------------- > > Key: WFLY-10319 > URL: https://issues.jboss.org/browse/WFLY-10319 > Project: WildFly > Issue Type: Bug > Components: REST > Affects Versions: 12.0.0.Final > Reporter: Javier Estevez Sanchez > Assignee: Alessio Soldano > Priority: Major > > The following JAX-RS resource exposes two resources via a GET operation: /demo and /demo/subresource. The first one via a sub-resource method, the latter via a sub-resource locator. Additionally, a response filter is binded to the JAX-RS resource class to modify the response. From the JAX-RS 2.0 spec, §6.5.2 Name Binding: > {quote} > Binding annotations that decorate resource classes apply to all resource methods defined in them. > {quote} > However, the binding annotation is not applying to the sub-resource locator method. This happens when the name binding annotation is on the resource class or on the sub-resource locator method. Annotating the sub-resource class or the method within works as expected, though. > Below is the code needed to reproduce this issue: > {code:java|title=The resource and subresource} > @DemoNameBinding > @Produces(MediaType.APPLICATION_JSON) > @Path("/demo") > public class DemoResource { > @GET > public String getDemoValue() { > return "A value"; > } > @Path("/subresource") > public DemoSubResource getSubResource() { > return new DemoSubResource(); > } > public class DemoSubResource { > @GET > public String getDemoValue() { > return "A value"; > } > } > } > {code} > {code:java|title=The filter} > @Provider > @DemoNameBinding > public class SomeFilter implements ContainerResponseFilter { > @Override > public void filter(ContainerRequestContext requestContext, ContainerResponseContext responseContext) { > responseContext.setEntity("A filtered value"); > } > } > {code} > {code:java|title=The binding} > @NameBinding > @Target({ElementType.TYPE, ElementType.METHOD}) > @Retention(RetentionPolicy.RUNTIME) > public @interface DemoNameBinding { > } > {code} -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 8 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira February 2019