August 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-9213) Implement the Pause method for a Topic via Management APIs

by Jeff Mesnil (JIRA)

[ https://issues.jboss.org/browse/WFLY-9213?page=com.atlassian.jira.plugin.... ] Jeff Mesnil updated WFLY-9213: ------------------------------ Security: (was: Red Hat Internal) > Implement the Pause method for a Topic via Management APIs > ---------------------------------------------------------- > > Key: WFLY-9213 > URL: https://issues.jboss.org/browse/WFLY-9213 > Project: WildFly > Issue Type: Feature Request > Components: JMS > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > Labels: Previous_RFE > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2207) Use of AUTH does not result in a SecurityException if another client does not use AUTH

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2207?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-2207: -------------------------------- I noticed that a rejection message is indeed already sent in {{up(MessageBatch)}}, therefore this change aligned {{up(Message)}} more closely with {{up(MessageBatch)}}. > Use of AUTH does not result in a SecurityException if another client does not use AUTH > -------------------------------------------------------------------------------------- > > Key: JGRP-2207 > URL: https://issues.jboss.org/browse/JGRP-2207 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.0.4 > Reporter: Mirko Streckenbach > Assignee: Bela Ban > Fix For: 4.0.5 > > Attachments: JGroupsAuthExample.java, JGroupsAuthExample.java > > > If there are two members in a cluster, one with AUTH configured and started first, so it can become the coordinator and a second without AUTH, the documentation implies that the second should receive a SecurityException. Instead, it creates it's own cluster. This works as expected if the second member uses AUTH, but has a different SecurityToken. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2207) Use of AUTH does not result in a SecurityException if another client does not use AUTH

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2207?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-2207: -------------------------------- Got you: you want the second member's JOIN request to fail and it to terminate rather than forming a separate cluster. Again, while I don't think forming a separate cluster is a bad idea (remember: the main goal is for the second member *not* to join the first member's cluster), I changed the code to: {code:java} AuthHeader auth_hdr=msg.getHeader(id); if(auth_hdr == null) { sendRejectionMessage(gms_hdr.getType(), msg.src(), "no AUTH header found in message"); throw new IllegalStateException(String.format("found %s from %s but no AUTH header", gms_hdr, msg.src())); } {code} So now a rejection message is sent to the joiner before throwing the exception, which is a minimal non-invasive change. WDYT? > Use of AUTH does not result in a SecurityException if another client does not use AUTH > -------------------------------------------------------------------------------------- > > Key: JGRP-2207 > URL: https://issues.jboss.org/browse/JGRP-2207 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.0.4 > Reporter: Mirko Streckenbach > Assignee: Bela Ban > Fix For: 4.0.5 > > Attachments: JGroupsAuthExample.java, JGroupsAuthExample.java > > > If there are two members in a cluster, one with AUTH configured and started first, so it can become the coordinator and a second without AUTH, the documentation implies that the second should receive a SecurityException. Instead, it creates it's own cluster. This works as expected if the second member uses AUTH, but has a different SecurityToken. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3042) It is not possible to add new Elytron policy after adding and removing it first

by Martin Stefanko (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3042?page=com.atlassian.jira.plugi... ] Martin Stefanko resolved WFCORE-3042. ------------------------------------- Resolution: Rejected As comment [1] stated, the legacy security Jacc configuration needs to be disabled before the use of Elytron Jacc policy provider. This configuration is considered sufficient as Elytron will eventually replace PicketBox as a default security implementation so I am resolving this as rejected. [1] https://issues.jboss.org/browse/JBEAP-11861?focusedCommentId=13445648&pag... > It is not possible to add new Elytron policy after adding and removing it first > ------------------------------------------------------------------------------- > > Key: WFCORE-3042 > URL: https://issues.jboss.org/browse/WFCORE-3042 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Jan Kašík > Assignee: Martin Stefanko > > Adding new Elytron policy fails if it was previously added and then removed. Next adding fails [1] and with exception [2] in server.log. > [1] > {code} > [standalone@localhost:9990 /] /subsystem=elytron/policy=jacc:add(jacc-policy=[{name => jacc}]) > { > "outcome" => "failed", > "response-headers" => { > "operation-requires-reload" => true, > "process-state" => "reload-required" > }, > "failure-description" => {"WFLYCTL0080: Failed services" => {"org.wildfly.security.policy" => "Failed to start service > Caused by: java.lang.RuntimeException: Failed to set policy [org.wildfly.security.authz.jacc.JaccDelegatingPolicy@502d9a84] > Caused by: java.lang.SecurityException: ELY03018: Cannot add permissions to a read-only permission collection"}}, > "rolled-back" => true > } > {code} > [2] > {code} > 2017-06-29 11:08:35,700 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service org.wildfly.security.policy: org.jboss.msc.service.StartException in service org.wildfly.security.policy: Failed to start service > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1978) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:748) > Caused by: java.lang.RuntimeException: Failed to set policy [org.wildfly.security.authz.jacc.JaccDelegatingPolicy@502d9a84] > at org.wildfly.extension.elytron.PolicyDefinitions$1$1.start(PolicyDefinitions.java:177) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955) > ... 3 more > Caused by: java.lang.SecurityException: ELY03018: Cannot add permissions to a read-only permission collection > at org.wildfly.security.authz.jacc.JaccDelegatingPolicy$1.add(JaccDelegatingPolicy.java:126) > at java.security.Policy.addStaticPerms(Policy.java:686) > at java.security.Policy.getPermissions(Policy.java:673) > at org.jboss.security.jacc.DelegatingPolicy.getPermissions(DelegatingPolicy.java:125) > at java.security.Policy.initPolicy(Policy.java:327) > at java.security.Policy.setPolicy(Policy.java:270) > at org.wildfly.extension.elytron.PolicyDefinitions$1$1.lambda$setPolicyAction$0(PolicyDefinitions.java:201) > at org.wildfly.extension.elytron.PolicyDefinitions$1$1.setPolicy(PolicyDefinitions.java:195) > at org.wildfly.extension.elytron.PolicyDefinitions$1$1.start(PolicyDefinitions.java:173) > ... 5 more > 2017-06-29 11:08:35,701 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 3) WFLYCTL0013: Operation ("add") failed - address: ([ > ("subsystem" => "elytron"), > ("policy" => "jacc") > ]) - failure description: {"WFLYCTL0080: Failed services" => {"org.wildfly.security.policy" => "Failed to start service > Caused by: java.lang.RuntimeException: Failed to set policy [org.wildfly.security.authz.jacc.JaccDelegatingPolicy@502d9a84] > Caused by: java.lang.SecurityException: ELY03018: Cannot add permissions to a read-only permission collection"}} > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-1323) Performance issue in audit endpoints

by Josef Cacek (JIRA)

Josef Cacek created ELY-1323: -------------------------------- Summary: Performance issue in audit endpoints Key: ELY-1323 URL: https://issues.jboss.org/browse/ELY-1323 Project: WildFly Elytron Issue Type: Bug Components: Audit Affects Versions: 1.1.0.CR4 Reporter: Josef Cacek Assignee: Darran Lofthouse Priority: Blocker Attachments: elytron-flightrecording.jfr Synchronization in audit endpoint implementations leads to a great performance drop. We see the issue in {{FileAuditEndpoint.accept(EventPriority, String)}}, but similar code is also in the {{SyslogAuditEndpoint}}. Check the attached recording (FlightRecorder) in jmc (Java Mission Control). It can be seen in these tabs - Threads > Contention - Threads > Thread Dumps - Threads > Lock Instances -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9212) Cannot control what principal JAASIdentityManagerImpl for SecurityContextUtil#createSubjectInfo(Principal, Object, Subject)

by Scott Stark (JIRA)

Scott Stark created WFLY-9212: --------------------------------- Summary: Cannot control what principal JAASIdentityManagerImpl for SecurityContextUtil#createSubjectInfo(Principal, Object,Subject) Key: WFLY-9212 URL: https://issues.jboss.org/browse/WFLY-9212 Project: WildFly Issue Type: Feature Request Components: Security Affects Versions: 10.1.0.Final Reporter: Scott Stark Assignee: Darran Lofthouse I have a custom JWT based auth method and JAAS login module that I'm testing with swarm which is using WFLY 10.1.0.Final. I am not able to install a custom Principal instance for retrieval via the JAX-RS javax.ws.rs.core.SecurityContext#getUserPrincipal() because of how the JAASIdentityManagerImpl#verifyCredential(final AccountImpl account, final Object credential) method populates the SecurityContext.SecurityContextUtil SubjectInfo. The following line: https://github.com/wildfly/wildfly/blob/c3332cec0c9bc5dc57899c2ae7ba26dd0... sc.getUtil().createSubjectInfo(incomingPrincipal, credential, subject); Is using the incomingPrincipal, which is derived from the simple AccountImpl wrapping of the incoming String id. In my call path, this is the user id before any authentication has happened as there is no originalPrincipal value on the AccountImpl, so it is not the best representation of the authenticated caller, and the wrapping Principal instance does not exist amongst the authenticated Subject#getPrincipals(). I see this is due to a CallerPrincipal issue: https://issues.jboss.org/browse/WFLY-3626 but one needs to be able to control what form of the authenticated userPrincipal that is returned by the user face container getUserPrincipal() call See the getPrincipalClass() unit test in this repo for an example of what is being tested: https://github.com/MicroProfileJWT/microprofile-jwt-auth-wfswarm/blob/f39... I can work around this by overriding the SubjectInfo by immediately after the auth mechanism has called the SecurityContext#authenticationComplete(...) using: // Workaround authenticated JWTPrincipal not being installed as user principal org.jboss.security.SecurityContext jbSC = SecurityContextAssociation.getSecurityContext(); Subject subject = jbSC.getUtil().getSubject(); jbSC.getUtil().createSubjectInfo(jwtPrincipal, bearerToken, subject); I have tried wrapping the Account passed into SecurityContext#authenticationComplete(...) and that has not worked so far, but I'll look again to see if there is something else I can override to achieve the desired behavior. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4699) Expose EJB3 deployment information at runtime

by Brad Maxwell (JIRA)

[ https://issues.jboss.org/browse/WFLY-4699?page=com.atlassian.jira.plugin.... ] Brad Maxwell updated WFLY-4699: ------------------------------- Description: User will be able to get EJB Deployment Information at runtime for the following areas: - Class name - Local JNDI name - Remote JNDI name - Security roles - Bean statistics (beans in use, access count, idle count, ...) - Destination JNDI (for MDBs) - Activation config properties - EJB timeout (Stateful Timeouts , and Stateless Instance timeout) A lot of this information were previously (EAP 5) obtained from the deployment descriptor that was published by the bean ("deploymentDescriptor" attribute). In the past, this metadata could be retrieved from EAP 5 via jmx which no longer exists in EAP 6+ (JBoss AS 7+). Now with EJB 3, users provide that information through annotations (and also through the Deployment Descriptor file), so users need means to get those informations at runtime. The goal of this is not only for MDB but for all kinds of EJB (session, stateful, MDB, ...) MORE INFO: The local and remote JNDI are related to Session EJBs. However we need to access the JNDI of the destination configured for the MDB. was: User will be able to get EJB Deployment Information at runtime for the following areas: - Class name - Local JNDI name - Remote JNDI name - Security roles - Bean statistics (beans in use, access count, idle count, ...) - Destination JNDI (for MDBs) - Activation config properties A lot of this information were previously (EAP 5) obtained from the deployment descriptor that was published by the bean ("deploymentDescriptor" attribute). In the past, this metadata could be retrieved from EAP 5 via jmx which no longer exists in EAP 6+ (JBoss AS 7+). Now with EJB 3, users provide that information through annotations (and also through the Deployment Descriptor file), so users need means to get those informations at runtime. The goal of this is not only for MDB but for all kinds of EJB (session, stateful, MDB, ...) MORE INFO: The local and remote JNDI are related to Session EJBs. However we need to access the JNDI of the destination configured for the MDB. > Expose EJB3 deployment information at runtime > --------------------------------------------- > > Key: WFLY-4699 > URL: https://issues.jboss.org/browse/WFLY-4699 > Project: WildFly > Issue Type: Feature Request > Components: EJB > Reporter: Bilge Ozpeynirci > Assignee: David Lloyd > Priority: Minor > > User will be able to get EJB Deployment Information at runtime for the following areas: > - Class name > - Local JNDI name > - Remote JNDI name > - Security roles > - Bean statistics (beans in use, access count, idle count, ...) > - Destination JNDI (for MDBs) > - Activation config properties > - EJB timeout (Stateful Timeouts , and Stateless Instance timeout) > A lot of this information were previously (EAP 5) obtained from the deployment descriptor that was published by the bean ("deploymentDescriptor" attribute). In the past, this metadata could be retrieved from EAP 5 via jmx which no longer exists in EAP 6+ (JBoss AS 7+). Now with EJB 3, users provide that information through annotations (and also through the Deployment Descriptor file), so users need means to get those informations at runtime. > The goal of this is not only for MDB but for all kinds of EJB (session, stateful, MDB, ...) > MORE INFO: > The local and remote JNDI are related to Session EJBs. > However we need to access the JNDI of the destination configured for the MDB. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBREM-1338) Authentication is not cached properly if the callback handler does not implement equals()/hashCode()

by Stuart Douglas (JIRA)

Stuart Douglas created JBREM-1338: ------------------------------------- Summary: Authentication is not cached properly if the callback handler does not implement equals()/hashCode() Key: JBREM-1338 URL: https://issues.jboss.org/browse/JBREM-1338 Project: JBoss Remoting Issue Type: Bug Reporter: Stuart Douglas If the callback handler does not implement equals()/hashCode() then AuthenticationConfiguration objects will not be considered equal (in the case where a new one is being created each time), which will result in a memory leak in org.jboss.remoting3.ConnectionPeerIdentityContext#futureAuths, as well as authentication being attempted for every request. This can be observed by adding a loop to org.jboss.as.test.integration.naming.remote.simple.RemoteNamingTestCase#testRemoteLookup I think this is a fairly serious issue, as I think there will be a lot of handler out there that do not meet this requirement, and it causes both a serious performance regression due to repeated auth, as well as a memory leak that can crash the JVM. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (HAWKULARQE-151) Avoid Trigger collisions - Sprint-65

by Michael Foley (JIRA)

[ https://issues.jboss.org/browse/HAWKULARQE-151?page=com.atlassian.jira.pl... ] Michael Foley commented on HAWKULARQE-151: ------------------------------------------ Does anybody know the corressponding developer's Jira(s) for this ? I want to have this QE Jira cross-referenced to the developer Jira ... and to have this summary test information copied into the developer Jira ...so they can see and are aware of the test results. > Avoid Trigger collisions - Sprint-65 > ------------------------------------ > > Key: HAWKULARQE-151 > URL: https://issues.jboss.org/browse/HAWKULARQE-151 > Project: Hawkular QE > Issue Type: Task > Reporter: Matt Mahoney > Assignee: Sunil kondkar > > Avoid Trigger collisions when Hawkular is linked to multiple MIQ installations > Ref Sprint Review: https://www.youtube.com/watch?v=nXLLLv_QyP0&feature=em-subs_digest -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (HAWKULARQE-151) Avoid Trigger collisions - Sprint-65

by Guilherme Baufaker Rêgo (JIRA)

[ https://issues.jboss.org/browse/HAWKULARQE-151?page=com.atlassian.jira.pl... ] Guilherme Baufaker Rêgo edited comment on HAWKULARQE-151 at 8/8/17 5:23 PM: ---------------------------------------------------------------------------- Documenting test summary Enhancement (https://github.com/ManageIQ/manageiq-providers-hawkular/pull/22/files) Hawkular Board (https://issues.jboss.org/browse/HAWKULARQE-151) Test Plan (https://polarion.engineering.redhat.com/polarion/#/project/JBossON4/testr...) 3 Test Cases (2 passed, 1 fail) Issues Found ManageIQ Latest Docker is not working RHEL 7.4 Atomic https://github.com/ManageIQ/manageiq/issues/15703 Hawkular Agent Unable to connect to Hawkular Services on Openshift https://github.com/hawkular/hawkular-services/issues/172 Events don’t show on Middleware Provider Timeline https://github.com/ManageIQ/manageiq/issues/15756 Tag Queries may produce Cassandra Busy Pool https://issues.jboss.org/projects/HWKALERTS/issues/HWKALERTS-275 was (Author: mfoley): Documenting test summary Enhancement (https://github.com/ManageIQ/manageiq-providers-hawkular/pull/22/files) Hawkular Board (https://issues.jboss.org/browse/HAWKULARQE-151) Test Plan ( 3 Test Cases (2 passed, 1 fail) Issues Found ManageIQ Latest Docker is not working RHEL 7.4 Atomic https://github.com/ManageIQ/manageiq/issues/15703 Hawkular Agent Unable to connect to Hawkular Services on Openshift https://github.com/hawkular/hawkular-services/issues/172 Events don’t show on Middleware Provider Timeline https://github.com/ManageIQ/manageiq/issues/15756 Tag Queries may produce Cassandra Busy Pool https://issues.jboss.org/projects/HWKALERTS/issues/HWKALERTS-275 > Avoid Trigger collisions - Sprint-65 > ------------------------------------ > > Key: HAWKULARQE-151 > URL: https://issues.jboss.org/browse/HAWKULARQE-151 > Project: Hawkular QE > Issue Type: Task > Reporter: Matt Mahoney > Assignee: Sunil kondkar > > Avoid Trigger collisions when Hawkular is linked to multiple MIQ installations > Ref Sprint Review: https://www.youtube.com/watch?v=nXLLLv_QyP0&feature=em-subs_digest -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 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 2017