May 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (ELY-1822) security domain with multiple realms

by Christopher Willems (Jira)

[ https://issues.jboss.org/browse/ELY-1822?page=com.atlassian.jira.plugin.s... ] Christopher Willems updated ELY-1822: ------------------------------------- Issue Type: Clarification (was: Bug) Priority: Optional (was: Major) closing this , adding the following is required <constant-realm-mapper name="constant-jdbc-realm" realm-name="jdbc-realm"/> <constant-realm-mapper name="constant-jwt-realm" realm-name="jwt-realm"/> > security domain with multiple realms > ------------------------------------- > > Key: ELY-1822 > URL: https://issues.jboss.org/browse/ELY-1822 > Project: WildFly Elytron > Issue Type: Clarification > Components: Authentication Server > Affects Versions: 1.8.0.Final > Environment: windows mssql > Reporter: Christopher Willems > Priority: Optional > Attachments: D95_J00_VM-DEV95-LS01, D95_J00_VM-DEV95-LS01.1, D95_J00_VM-DEV95-LS01.2, D95_SCS01_VM-DEV95-LS01, DEFAULT.PFL, HistorianMIIActionBlock - Shortcut.lnk, HistorianMIIActionBlock.zip, MaterialLotServicesMII.java, MovilitasFileHandling.zip, config-jwt-elytron.cli, config-jwtnw-elytron.cli, config-jwtnw-elytron.cli.txt, defaultTrace_00.8, defaultTrace_00.8.trc, defaultTracehana.txt, demofile.txt, editingactivitieswithnestedactivities.txt, inxites.be~inx~veri95.ejb.jar, jboss-ejb-client.properties, jboss-ejb3.xml, jboss-ejb3.xml, jboss-web.xml, jboss-web.xml, public.txt, server.log, standalone.xml > > > we have an ear file with 2 war files and one ejb jar . Purpose of the war files is to allow for different authentication mechanisms, one for jwt (BEARER_TOKEN) the other one jdbc (BASIC) . > After the authentication we have a call to the ejb layer which we expect to have the principal of the authentication. > Everything works fine for one realm, the default realm. The other realm will return unauthorized . With no default nothing works. The relevant information from the standalone xml is pasted below and others are attached. > <subsystem xmlns="urn:jboss:domain:ejb3:5.0"> > <default-security-domain value="other"/> > <application-security-domains> > <application-security-domain name="war-domain" security-domain="war-domain"/> > </application-security-domains> > <default-missing-method-permissions-deny-access value="false"/> > > <subsystem xmlns="urn:wildfly:elytron:6.0" > <security-domain name="war-domain" default-realm="jdbc-realm" permission-mapper="default-permission-mapper" outflow-security-domains="ApplicationDomain"> > <realm name="jdbc-realm"/> > <realm name="jwt-realm"/> > </security-domain> > > <http-authentication-factory name="war-http-authentication" security-domain="war-domain" http-server-mechanism-factory="global"> > <mechanism-configuration> > <mechanism mechanism-name="BEARER_TOKEN"> > <mechanism-realm realm-name="jwt-realm"/> > </mechanism> > <mechanism mechanism-name="BASIC"> > <mechanism-realm realm-name="jdbc-realm"/> > </mechanism> > </mechanism-configuration> > </http-authentication-factory> > below the exert from the log on using the jdbc realm when jwt is the default > 2019-05-30 15:28:05,290 TRACE [org.wildfly.security.http.servlet] (default task-1) No AuthConfigProvider for layer=HttpServlet, appContext=default-host /veri95web > 2019-05-30 15:28:05,290 TRACE [org.wildfly.security.http.servlet] (default task-1) JASPIC Unavailable, using HTTP authentication. > 2019-05-30 15:28:05,290 TRACE [org.wildfly.security] (default task-1) No CachedIdentity to restore. > 2019-05-30 15:28:05,290 TRACE [org.wildfly.security] (default task-1) Created HttpServerAuthenticationMechanism [org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$1@1505d380] for mechanism [BASIC] > 2019-05-30 15:28:05,290 TRACE [org.wildfly.security] (default task-1) Handling MechanismInformationCallback type='HTTP' name='BASIC' host-name='localhost' protocol='http' > 2019-05-30 15:28:05,290 TRACE [org.wildfly.security] (default task-1) Handling AvailableRealmsCallback: realms = [jdbc-realm] > 2019-05-30 15:28:05,290 DEBUG [org.wildfly.security.http.password] (default task-1) Username authentication. Realm: [jdbc-realm], Username: [user1]. > 2019-05-30 15:28:05,290 TRACE [org.wildfly.security] (default task-1) Handling RealmCallback: selected = [jdbc-realm] > 2019-05-30 15:28:05,291 TRACE [org.wildfly.security] (default task-1) Handling NameCallback: authenticationName = user1 > 2019-05-30 15:28:05,291 TRACE [org.wildfly.security] (default task-1) Principal assigning: [user1], pre-realm rewritten: [user1], realm name: [jwt-realm], post-realm rewritten: [user1], realm rewritten: [user1] > 2019-05-30 15:28:05,291 DEBUG [org.wildfly.security.http.basic] (default task-1) User user1 authentication failed. > 2019-05-30 15:28:05,291 TRACE [org.wildfly.security] (default task-1) Handling AuthenticationCompleteCallback: fail > 2019-05-30 15:28:05,291 DEBUG [io.undertow.request.security] (default task-1) Authentication failed with message ELY06002: An authentication attempt for user 'user1' failed validation using mechanism 'BASIC'. and mechanism BASIC for HttpServerExchange{ POST /veri95web/rest/Xml/process/Equipment request {Accept=[*/*], Postman-Token=[9bba6216-81a7-4048-aa24-ec110d677e4a], Cache-Control=[no-cache], accept-encoding=[gzip, deflate], User-Agent=[PostmanRuntime/7.13.0], Connection=[keep-alive], Authorization=[Basic dXNlcjE6MGZmZDkzNDkyNzgzNzE5YQ==], Content-Type=[applicati > [^server.log] -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-4067) Add before/afterNodeEvaluated to enable monitoring of engine performance

by Mario Fusco (Jira)

[ https://issues.jboss.org/browse/DROOLS-4067?page=com.atlassian.jira.plugi... ] Mario Fusco updated DROOLS-4067: -------------------------------- Sprint: 2019 Week 23-25 (was: 2019 Week 20-22) > Add before/afterNodeEvaluated to enable monitoring of engine performance > ------------------------------------------------------------------------ > > Key: DROOLS-4067 > URL: https://issues.jboss.org/browse/DROOLS-4067 > Project: Drools > Issue Type: Enhancement > Components: core engine > Reporter: Mario Fusco > Assignee: Mario Fusco > Priority: Major > -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-4070) Improve service discovery/wiring to allow defining the order of alternative services

by Mario Fusco (Jira)

[ https://issues.jboss.org/browse/DROOLS-4070?page=com.atlassian.jira.plugi... ] Mario Fusco updated DROOLS-4070: -------------------------------- Sprint: 2019 Week 23-25 (was: 2019 Week 20-22) > Improve service discovery/wiring to allow defining the order of alternative services > ------------------------------------------------------------------------------------ > > Key: DROOLS-4070 > URL: https://issues.jboss.org/browse/DROOLS-4070 > Project: Drools > Issue Type: Enhancement > Components: core engine > Reporter: Mario Fusco > Assignee: Mario Fusco > Priority: Critical > -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-4095) Null-safe dereferencing operator cannot be used after a method invocation

by Mario Fusco (Jira)

[ https://issues.jboss.org/browse/DROOLS-4095?page=com.atlassian.jira.plugi... ] Mario Fusco resolved DROOLS-4095. --------------------------------- Tester: Tibor Zimanyi Resolution: Done Fixed by https://github.com/kiegroup/drools/commit/e57a437f2c1cb5aae3fd309accb5880... > Null-safe dereferencing operator cannot be used after a method invocation > ------------------------------------------------------------------------- > > Key: DROOLS-4095 > URL: https://issues.jboss.org/browse/DROOLS-4095 > Project: Drools > Issue Type: Bug > Components: core engine > Reporter: Mario Fusco > Assignee: Mario Fusco > Priority: Major > -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-4095) Null-safe dereferencing operator cannot be used after a method invocation

by Mario Fusco (Jira)

[ https://issues.jboss.org/browse/DROOLS-4095?page=com.atlassian.jira.plugi... ] Mario Fusco commented on DROOLS-4095: ------------------------------------- A constraint using the null-safe derefencing operator like address!.street == $street works without problems while the drl parser fails with a method invocation like getAddress()!.street == $street > Null-safe dereferencing operator cannot be used after a method invocation > ------------------------------------------------------------------------- > > Key: DROOLS-4095 > URL: https://issues.jboss.org/browse/DROOLS-4095 > Project: Drools > Issue Type: Bug > Components: core engine > Reporter: Mario Fusco > Assignee: Mario Fusco > Priority: Major > -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-4095) Null-safe dereferencing operator cannot be used after a method invocation

by Mario Fusco (Jira)

Mario Fusco created DROOLS-4095: ----------------------------------- Summary: Null-safe dereferencing operator cannot be used after a method invocation Key: DROOLS-4095 URL: https://issues.jboss.org/browse/DROOLS-4095 Project: Drools Issue Type: Bug Components: core engine Reporter: Mario Fusco Assignee: Mario Fusco -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JGRP-2351) TCP: connection close can block when send() block on full TCP send-window

by Wolf-Dieter Fink (Jira)

Wolf-Dieter Fink created JGRP-2351: -------------------------------------- Summary: TCP: connection close can block when send() block on full TCP send-window Key: JGRP-2351 URL: https://issues.jboss.org/browse/JGRP-2351 Project: JGroups Issue Type: Bug Reporter: Wolf-Dieter Fink Assignee: Bela Ban Fix For: 4.1.1 When a peer is non-responsive (without closing its socket), a TcpConnection.send() can block on a write (state is RUNNABLE!). The problem is that the TcpConnection cannout be closed either, as TcpConnection.close() tries to acquire the same lock already held by TcpConnection.send(). See the stack trace below for a sample scenario. The use case is this one: * Say we have nodes A (coord), B and C * There's heavy (clustering) traffic to all 3 nodes, from the 2 clients * B is isolated by executing 'ifdown bond0' * At this point, the messages going to B will back up at (say) A because A doesn't get any TCP acks from B * At some point, depending on the traffic and the size of the sent messages, A will acquire a lock on the send connection to B, to write data, but the write will block as the TCP send-window to B is full (note that the sender thread will still be in state RUNNABLE!) * After 40s, A suspects B and emits a new view {A,C} * This causes A's connection to B to be closed and subsequently removed. However, this _won't_ happen, as the connection close will need to acquire the connection lock, which is held by the TCP write {noformat} "main" #1 prio=5 os_prio=31 tid=0x00007fbbd3802000 nid=0x2303 runnable [0x0000700009793000] java.lang.Thread.State: RUNNABLE at java.net.SocketOutputStream.socketWrite0(Native Method) at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:111) at java.net.SocketOutputStream.write(SocketOutputStream.java:155) at java.io.BufferedOutputStream.write(BufferedOutputStream.java:122) - locked <0x000000079e790a50> (a java.io.BufferedOutputStream) at java.io.DataOutputStream.write(DataOutputStream.java:107) - locked <0x000000079e790838> (a java.io.DataOutputStream) at org.jgroups.blocks.cs.TcpConnection.doSend(TcpConnection.java:161) at org.jgroups.blocks.cs.TcpConnection.send(TcpConnection.java:131) at org.jgroups.blocks.cs.TcpClient.send(TcpClient.java:103) at org.jgroups.tests.bla6.main(bla6.java:35) "Thread-2" #15 prio=5 os_prio=31 tid=0x00007fbbd2150800 nid=0x6503 waiting on condition [0x000070000bcf6000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <0x000000079e7871a8> (a java.util.concurrent.locks.ReentrantLock$NonfairSync) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:870) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1199) at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:209) at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:285) at org.jgroups.blocks.cs.TcpConnection.close(TcpConnection.java:358) at org.jgroups.util.Util.close(Util.java:422) at org.jgroups.blocks.cs.TcpClient.stop(TcpClient.java:85) at org.jgroups.blocks.cs.BaseServer.close(BaseServer.java:147) at org.jgroups.util.Util.close(Util.java:422) at org.jgroups.tests.bla6.lambda$main$0(bla6.java:27) at org.jgroups.tests.bla6$$Lambda$1/1384010761.run(Unknown Source) at java.lang.Thread.run(Thread.java:748) {noformat} -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-4094) Replace DmnName input element in SettingsDock to DropDown widget

by Yeser Amer (Jira)

Yeser Amer created DROOLS-4094: ---------------------------------- Summary: Replace DmnName input element in SettingsDock to DropDown widget Key: DROOLS-4094 URL: https://issues.jboss.org/browse/DROOLS-4094 Project: Drools Issue Type: Enhancement Components: Scenario Simulation and Testing Reporter: Yeser Amer Assignee: Yeser Amer -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-1160) Provide ability to easily apply certain JBoss module libraries to all deployments running in a server

by Harald Pehl (Jira)

[ https://issues.jboss.org/browse/WFLY-1160?page=com.atlassian.jira.plugin.... ] Harald Pehl updated WFLY-1160: ------------------------------ Labels: affects-model regression (was: regression) > Provide ability to easily apply certain JBoss module libraries to all deployments running in a server > ----------------------------------------------------------------------------------------------------- > > Key: WFLY-1160 > URL: https://issues.jboss.org/browse/WFLY-1160 > Project: WildFly > Issue Type: Feature Request > Components: Class Loading > Environment: All > Reporter: Paul Hinds > Assignee: Yeray Borges > Priority: Minor > Labels: affects-model, regression > > This page https://community.jboss.org/wiki/HowToPutAnExternalFileInTheClasspath details how to put a directory on the AS7 classpath which is inconvenient and could easily be done by default. > If AS7 out of the box came with /standalone/classes or /standalone/conf (conf would introduce a bit of backwards compatability) and perhaps /standalone/lib/*.jar added to the classpath it would be as good as previous JBoss versions. > This could be implemented as a module as in the above documents and automatically added to classpaths if the dirs exists in the same way other modules are automatically added to the CP if certain criteria are met. > Ideally is should be possible to make these symlinks on win7 and nix. Since it is natural to put config in /etc per Linux file system standards. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

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

by Harald Pehl (Jira)

[ https://issues.jboss.org/browse/WFCORE-3947?page=com.atlassian.jira.plugi... ] Harald Pehl updated WFCORE-3947: -------------------------------- Labels: affects-model (was: ) > Support SSL Certificate revocation using OCSP > --------------------------------------------- > > Key: WFCORE-3947 > URL: https://issues.jboss.org/browse/WFCORE-3947 > Project: WildFly Core > Issue Type: Feature Request > Components: Security > Affects Versions: 6.0.0.Alpha2 > Reporter: Jan Kalina > Assignee: Martin Mazanek > Priority: Major > Labels: affects-model > Fix For: 10.0.0.Beta1 > > > - 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)

7 years, 1 month

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 May 2019