September 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-13884) JdrReportManagmentTestCase.generateStandaloneJdrReport fails on my ee9 branch

by Yeray Borges Santana (Jira)

[ https://issues.redhat.com/browse/WFLY-13884?page=com.atlassian.jira.plugi... ] Yeray Borges Santana commented on WFLY-13884: --------------------------------------------- [~brian.stansberry] The problem is in the regular expression used to get the sos_strings entries. In the case of using the alt feature pack the directory name is wildfly_ee instead of wildfly_full. That's the same failure hit on your ee-9 branch. We can fix the regular expression, however, the dependency between the directory name and the distribution does not sound useful at all, maybe it would be better to generate the entries always as sos_strings/wildfly/... and avoid the recurrent modification of the regular expression. We could add the distribution name, version or whatever in a file inside of the report. > JdrReportManagmentTestCase.generateStandaloneJdrReport fails on my ee9 branch > ----------------------------------------------------------------------------- > > Key: WFLY-13884 > URL: https://issues.redhat.com/browse/WFLY-13884 > Project: WildFly > Issue Type: Bug > Components: JDR > Reporter: Brian Stansberry > Assignee: Yeray Borges Santana > Priority: Major > > On my ee9 branch JdrReportManagmentTestCase.generateStandaloneJdrReport fails when -Dts.ee9 us used. I'll disable it but we need to figure out why. > As part of whatever the fix is I'd like the sos_logs/skips.log to get special handling. Check it before checking the other files, and instead of just failing if not empty, capture the file contents and put them in the failure message. If there are future failures that will provide better info, even if the file is empty and the check passes, which would rule out a category of problems. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 8 months

1
0
0 / 0

[JBoss JIRA] (SSLNTV-8) Sessions not removed correctly

by Farah Juma (Jira)

[ https://issues.redhat.com/browse/SSLNTV-8?page=com.atlassian.jira.plugin.... ] Farah Juma moved WFSSL-52 to SSLNTV-8: -------------------------------------- Project: WildFly OpenSSL Natives (was: WildFly OpenSSL) Key: SSLNTV-8 (was: WFSSL-52) > Sessions not removed correctly > ------------------------------ > > Key: SSLNTV-8 > URL: https://issues.redhat.com/browse/SSLNTV-8 > Project: WildFly OpenSSL Natives > Issue Type: Bug > Reporter: Stuart Douglas > Assignee: Stuart Douglas > Priority: Major > > SSL_SESSION_free(session) needs to be called by remove_session_cb, otherwise a memory leak occurs. This leak is normally small but if client cert auth is used then it is very large as the session contains the certificates. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13589) WildFly cannot connect to an infinispan-server cluster requiring authentication

by Thomas Jenkinson (Jira)

[ https://issues.redhat.com/browse/WFLY-13589?page=com.atlassian.jira.plugi... ] Thomas Jenkinson commented on WFLY-13589: ----------------------------------------- [~rhusar] please can you comment on how this relates to (or not) https://issues.redhat.com/browse/WFLY-13854? Thanks! > WildFly cannot connect to an infinispan-server cluster requiring authentication > ------------------------------------------------------------------------------- > > Key: WFLY-13589 > URL: https://issues.redhat.com/browse/WFLY-13589 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 20.0.0.Final > Reporter: Paul Ferraro > Assignee: Radoslav Husar > Priority: Critical > > Infinispan 11.0 requires authentication by default. Consequently, we need the ability to configure authentication for a remote-cache-container. > See: [https://infinispan.org/blog/2020/06/04/server-secure-by-default/] > See also: [https://infinispan.org/docs/dev/titles/server/server.html#security] > To future-proof this, we should also allow informal adhoc properties (like we already do for JGroups protocols and cache stores) - which are processed by the hotrod client before any formal properties from the model. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13888) Move JWTEJBTestCase to testsuite/integration/microprofile

by Brian Stansberry (Jira)

[ https://issues.redhat.com/browse/WFLY-13888?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFLY-13888: ----------------------------------------- Ah, ok. Permutations suck. > Move JWTEJBTestCase to testsuite/integration/microprofile > --------------------------------------------------------- > > Key: WFLY-13888 > URL: https://issues.redhat.com/browse/WFLY-13888 > Project: WildFly > Issue Type: Task > Components: MP JWT > Reporter: Brian Stansberry > Assignee: Darran Lofthouse > Priority: Major > > Part of our overall testing strategy is wanting to be able to run testsuite/integration/basic using the output of the ee-build maven module or provisioning using the wildfly-ee feature pack. Having a JWT test in that testsuite breaks that. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 8 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5557) kie-dmn-validation migration to exec model

by Matteo Mortari (Jira)

[ https://issues.redhat.com/browse/DROOLS-5557?page=com.atlassian.jira.plug... ] Matteo Mortari resolved DROOLS-5557. ------------------------------------ Resolution: Done Marking this User Story as Done, since all features complete and a Blog post + quick video illustrating the feature in details > kie-dmn-validation migration to exec model > ------------------------------------------ > > Key: DROOLS-5557 > URL: https://issues.redhat.com/browse/DROOLS-5557 > Project: Drools > Issue Type: Story > Components: dmn engine > Reporter: Matteo Mortari > Assignee: Matteo Mortari > Priority: Major > > kie-dmn-validation migration to exec model -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 8 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-1218) Create secrets for registry.stage.redhat.io during OCP installation

by Filip Brychta (Jira)

[ https://issues.redhat.com/browse/SWSQE-1218?page=com.atlassian.jira.plugi... ] Filip Brychta resolved SWSQE-1218. ---------------------------------- Resolution: Done Added ADD_REDHAT_STAGE_REGISTRY_PULL_SECRET to both IPI and UPI > Create secrets for registry.stage.redhat.io during OCP installation > ------------------------------------------------------------------- > > Key: SWSQE-1218 > URL: https://issues.redhat.com/browse/SWSQE-1218 > Project: Kiali QE > Issue Type: QE Task > Reporter: Filip Brychta > Assignee: Filip Brychta > Priority: Major > Labels: infrastructure > > Do we want to add it always during OCP installation of only when installing something from registry.stage.redhat.com ? > Ping Jeeva -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13891) Make security service dependency optional for webservice deployment

by Jim Ma (Jira)

Jim Ma created WFLY-13891: ----------------------------- Summary: Make security service dependency optional for webservice deployment Key: WFLY-13891 URL: https://issues.redhat.com/browse/WFLY-13891 Project: WildFly Issue Type: Bug Components: Web Services Affects Versions: 21.0.0.Beta1 Reporter: Jim Ma Assignee: Jim Ma Fix For: 21.0.0.Final Webservice deployment all requires a security dependency to start EndpointService. This stops webservice galleon layer working without any security layer dependency. 18:45:19,859 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "jaxws-cxf-bus.war")]) - failure description: { "WFLYCTL0412: Required services that are not installed:" => ["jboss.security.security-domain.other"], "WFLYCTL0180: Services with missing/unavailable dependencies" => [ "jboss.ws.endpoint.\"jaxws-cxf-bus.war\".Ep2Servlet is missing [jboss.security.security-domain.other]", "jboss.ws.endpoint.\"jaxws-cxf-bus.war\".EpServlet is missing [jboss.security.security-domain.other]" ] } -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-5134) AuditLogToTLSSyslogTestCase stucks with oracle JDK 11

by Darran Lofthouse (Jira)

[ https://issues.redhat.com/browse/WFCORE-5134?page=com.atlassian.jira.plug... ] Darran Lofthouse reassigned WFCORE-5134: ---------------------------------------- Assignee: (was: Darran Lofthouse) > AuditLogToTLSSyslogTestCase stucks with oracle JDK 11 > ----------------------------------------------------- > > Key: WFCORE-5134 > URL: https://issues.redhat.com/browse/WFCORE-5134 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Jean Francois Denise > Priority: Major > > I am using oracle JDK 11, the test get stucks in tear down attempting to execute server tearDown action. I noticed that this test is not run on JDK12 due to a deadlock. The observed problem smells deadlock although jstack doesn't report any. > JDK: > java 11.0.8 2020-07-14 LTS > Java(TM) SE Runtime Environment 18.9 (build 11.0.8+10-LTS) > Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11.0.8+10-LTS, mixed mode) > -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13801) JWT Revoke Feature

by Darran Lofthouse (Jira)

[ https://issues.redhat.com/browse/WFLY-13801?page=com.atlassian.jira.plugi... ] Darran Lofthouse reassigned WFLY-13801: --------------------------------------- Assignee: (was: Darran Lofthouse) > JWT Revoke Feature > ------------------ > > Key: WFLY-13801 > URL: https://issues.redhat.com/browse/WFLY-13801 > Project: WildFly > Issue Type: Feature Request > Components: Security > Affects Versions: 20.0.1.Final > Reporter: Paulo Cesar Silva Reis > Priority: Major > > Hi, > > We've been working with JWT using Elytron and we would like to know why there isn't a way to REVOKE tokens. Reading the documentation it seems elytron doesn't provide a way to double-check whether that valid JWT still has access to the application. If a class could be instantiate and a method called, the application could validate it, returning a boolean (indicating whether the user can proceed) or throwing an exception when permission is denied. > If such feature isn't present, even though we blacklist the token (logging him out), the user already logged in and that can be a security breach. > > Something like this would be great: > {code:java} > /subsystem=elytron/token-realm=app-realm:add(jwt={issuer=["issuer"],audience=["app"],key-store=app.ks,certificate="alias", validator="com.validator.TokenValidator"},principal-claim="sub"){code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-5022) The /subsystem=elytron/policy=* can be simplified a lot further

by Darran Lofthouse (Jira)

[ https://issues.redhat.com/browse/WFCORE-5022?page=com.atlassian.jira.plug... ] Darran Lofthouse reassigned WFCORE-5022: ---------------------------------------- Assignee: (was: Darran Lofthouse) > The /subsystem=elytron/policy=* can be simplified a lot further > --------------------------------------------------------------- > > Key: WFCORE-5022 > URL: https://issues.redhat.com/browse/WFCORE-5022 > Project: WildFly Core > Issue Type: Enhancement > Components: Security > Affects Versions: 12.0.1.Final > Reporter: Darran Lofthouse > Priority: Major > > At the moment this resource is quite verbose but the tasks it performs are very simple. > {code:java} > [standalone@localhost:9990 /] /subsystem=elytron/policy=*:read-resource-description > { > "outcome" => "success", > "result" => [{ > "address" => [ > ("subsystem" => "elytron"), > ("policy" => "*") > ], > "outcome" => "success", > "result" => { > "description" => "A definition that sets up a policy provider.", > "max-occurs" => 1, > "capabilities" => [{ > "name" => "org.wildfly.security.policy", > "dynamic" => false > }], > "access-constraints" => { > "sensitive" => {"elytron-security" => {"type" => "elytron"}}, > "application" => {"elytron-security" => {"type" => "elytron"}} > }, > "attributes" => { > "custom-policy" => { > "type" => OBJECT, > "description" => "A custom policy provider definition.", > "expressions-allowed" => false, > "required" => true, > "nillable" => true, > "alternatives" => ["jacc-policy"], > "value-type" => { > "class-name" => { > "type" => STRING, > "description" => "The name of a java.security.Policy implementation referencing a policy provider.", > "expressions-allowed" => false, > "required" => true, > "nillable" => false, > "min-length" => 1L, > "max-length" => 2147483647L > }, > "module" => { > "type" => STRING, > "description" => "The name of the module to load the provider from.", > "expressions-allowed" => false, > "required" => false, > "nillable" => true, > "min-length" => 1L, > "max-length" => 2147483647L > } > }, > "access-type" => "read-write", > "storage" => "configuration", > "restart-required" => "no-services" > }, > "default-policy" => { > "type" => STRING, > "description" => "Not used.", > "expressions-allowed" => false, > "required" => false, > "nillable" => true, > "min-length" => 1L, > "max-length" => 2147483647L, > "deprecated" => { > "since" => "1.2.0", > "reason" => "The 'default-policy' attribute is ignored, as a policy resource should be configured with only one policy." > }, > "access-type" => "read-write", > "storage" => "configuration", > "restart-required" => "no-services" > }, > "jacc-policy" => { > "type" => OBJECT, > "description" => "A policy provider definition that sets up JACC and related services.", > "expressions-allowed" => false, > "required" => true, > "nillable" => true, > "alternatives" => ["custom-policy"], > "value-type" => { > "policy" => { > "type" => STRING, > "description" => "The name of a java.security.Policy implementation referencing a policy provider.", > "expressions-allowed" => false, > "required" => false, > "nillable" => true, > "default" => "org.wildfly.security.authz.jacc.JaccDelegatingPolicy", > "min-length" => 1L, > "max-length" => 2147483647L > }, > "configuration-factory" => { > "type" => STRING, > "description" => "The name of a javax.security.jacc.PolicyConfigurationFactory implementation referencing a policy configuration factory provider.", > "expressions-allowed" => false, > "required" => false, > "nillable" => true, > "default" => "org.wildfly.security.authz.jacc.ElytronPolicyConfigurationFactory", > "min-length" => 1L, > "max-length" => 2147483647L > }, > "module" => { > "type" => STRING, > "description" => "The name of the module to load the provider from.", > "expressions-allowed" => false, > "required" => false, > "nillable" => true, > "min-length" => 1L, > "max-length" => 2147483647L > } > }, > "access-type" => "read-write", > "storage" => "configuration", > "restart-required" => "no-services" > } > }, > "operations" => undefined, > "notifications" => undefined, > "children" => {} > } > }] > } > {code} > Firstly it only makes sense to have a single policy defined, the outcome of this resource is JVM wide registration so multiple definitions would lead to undefined behaviour. > Secondly this provides two primary functions. > 1. Instantation of [https://docs.oracle.com/javase/8/docs/api/java/security/Policy.html] and registration via a call to [https://docs.oracle.com/javase/8/docs/api/java/security/Policy.html#setPo...] > This first point needs a class name for the policy as well as a module. > 2. Registration of the JVM wide [https://jakarta.ee/specifications/platform/8/apidocs/javax/security/jacc/...] again needing a classname and module. > This is also not working correctly but the immediate bug is being addressed under WFCORE-5020 > The JACC APIs don't actually provide a nice way to register this so maybe this is something we should also propose via the spec, but this piece is effectively a class name and module name. > We have ended up with custom and jacc variants as alternatives. Really both variants are optional but if the resource is defined at least one must be set. > It may make sense for JACC to move to it's own subsystem for a couple of reasons. > The JVM wide policy will likely need to be possible in both subsystems but use a capability to ensure it is defined in only one. We probably should move it's registration into the boot operations so registration is complete before DUPs begin. > The PolicyConfigurationFactory would then be in a JACC subsystem only. Again handling during a boot operation may be preferable otherwise we see issues like WFLY-13615 but failing that ensuring the deployment depend upon the registration happening may be sufficient. > Additionally the resource has some hard coded class names for the Policy and PolicyConfigurationFactory, we probably should not have these as class names and instead default to them if not defined - this means we still need a way to optionally activate their registration if JACC is required on the server. > It probably should also be possible to independently set the module for Policy and PolicyContextHandler as these will presently be shared. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 8 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 September 2020