[JBoss JIRA] (WFCORE-4485) Support for multiple security realms - Distributed Identities
by Martin Mazánek (Jira)
[ https://issues.redhat.com/browse/WFCORE-4485?page=com.atlassian.jira.plug... ]
Martin Mazánek updated WFCORE-4485:
-----------------------------------
Git Pull Request: https://github.com/wildfly/wildfly-core/pull/4114
> Support for multiple security realms - Distributed Identities
> -------------------------------------------------------------
>
> Key: WFCORE-4485
> URL: https://issues.redhat.com/browse/WFCORE-4485
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Security
> Reporter: Farah Juma
> Assignee: Martin Mazánek
> Priority: Major
> Labels: CD17-Deferred, EAP-CD19, Previous_RFE
>
> By stacking LoginModules it was possible using PicketBox to attempt to authenticate using one remote store and if that failed try the next store in the list.
> This RFE is to consider the use case where identities could be located across multiple stores and how they are aggregated together.
> Additionally this use case should consider how the authorization information could be loaded from multiple sources and merged.
> This RFE is not about fail over in the event of a realm being unavailable although it may be related.
> This RFE is created as a result of comparing the differences between the PicketBox JAAS architecture and the Elytron architecture so I would not recommend this proceeds without some real world use cases identified.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (WFLY-13283) WFLYTX0001: Unable to roll back active transaction exception thrown from RTS inbound bridge
by Ondrej Chaloupka (Jira)
Ondrej Chaloupka created WFLY-13283:
---------------------------------------
Summary: WFLYTX0001: Unable to roll back active transaction exception thrown from RTS inbound bridge
Key: WFLY-13283
URL: https://issues.redhat.com/browse/WFLY-13283
Project: WildFly
Issue Type: Bug
Components: Transactions
Affects Versions: 19.0.0.Final
Reporter: Ondrej Chaloupka
Assignee: Ondrej Chaloupka
This is an integration problem of REST-AT transaction inbound bridge with WFTC client.
It's in the same way as there was for XTS txnbridge https://issues.redhat.com/browse/WFLY-9455
The trouble is that REST-AT bridge implementation works with Narayana transaction manager. All the calls which go to the {{javax.transaction.TransactionManager}} is integrated to Narayana transaction manager backed by {{AtomicActions}} etc.
But WildFly is fully integrated with WFTC TransactionManager as a wrapper over the Narayana one.
The inbound bridge manages merging the REST-AT context with JTA context. On incoming REST call the InboundBridge is started and resume a transaction:
https://github.com/jbosstm/narayana/blob/5.10.4.Final/rts/at/bridge/src/m...
It's implemented by `ContainerRequestFilter` which is invoked on incoming call before the method is executed:
https://github.com/jbosstm/narayana/blob/5.10.4.Final/rts/at/bridge/src/m...
After execution is needed the transaction would be suspended again. In current time it happens for Narayana transaction but not for the WFTC transaction
Narayana `ContainerResponseFilter` handling:
* https://github.com/jbosstm/narayana/blob/5.10.4.Final/rts/at/bridge/src/m...
* https://github.com/jbosstm/narayana/blob/5.10.4.Final/rts/at/bridge/src/m...
(btw. the same is about handling of JAX-WS XTS txnbridge: https://github.com/jbosstm/narayana/blob/5.10.4.Final/txbridge/src/main/j...)
Now the issue is that WFLY WFTC Transaction is not suspended on the outbound. It means the EJB still think there is an active transaction. But it's only the WFTC wrapper which wraps an empty Narayana transaction. All the real business work was done, the real transaction was suspended.
When the call leaves the EJB there is a action which ensures no transaction leaves the EJB method (https://github.com/wildfly/wildfly/blob/19.0.0.Final/transactions/src/mai...). When there is some active context it's rolled-back. So WFTC Transaction rollback is called but as the WFTC holds an empty wrapper the rollback finishes with exception server log message[1].
[1]
{quote}
ERROR [org.jboss.as.txn] (default task-1) WFLYTX0003: APPLICATION ERROR: transaction still active in request with status 0
ERROR [org.jboss.as.txn] (default task-1) WFLYTX0001: Unable to roll back active transaction: javax.transaction.SystemException: WFTXN0032: Rollback not allowed on imported transaction
at org.wildfly.transaction.client.LocalTransaction.rollbackAndDissociate(LocalTransaction.java:105)
at org.wildfly.transaction.client.ContextTransactionManager.rollback(ContextTransactionManager.java:83)
at org.jboss.as.txn.deployment.TransactionRollbackSetupAction.checkTransactionStatus(TransactionRollbackSetupAction.java:137)
at org.jboss.as.txn.deployment.TransactionRollbackSetupAction.teardown(TransactionRollbackSetupAction.java:67)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1543)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1541)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1541)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1541)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1541)
at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:249)
at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:78)
at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:99)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:376)
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:830)
at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
at java.lang.Thread.run(Thread.java:748)
{quote}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (WFLY-13281) Remove unused dependencies from org.jboss.as.jpa
by Ranabir Chakraborty (Jira)
Ranabir Chakraborty created WFLY-13281:
------------------------------------------
Summary: Remove unused dependencies from org.jboss.as.jpa
Key: WFLY-13281
URL: https://issues.redhat.com/browse/WFLY-13281
Project: WildFly
Issue Type: Sub-task
Components: Class Loading, JPA / Hibernate
Reporter: Ranabir Chakraborty
Assignee: Ranabir Chakraborty
Fix For: 20.0.0.Beta1
This issue folows up WFLY-11279. There are additional dependencies that can be removed from org.jboss.as.jpa.
The additional dependencies are:
* javax.annotation.api
* javax.resource.api
* javax.servlet.api
* org.jboss.common-beans
* org.jboss.threads
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (WFLY-13282) Remove unused dependencies from org.jboss.as.jpa
by Ranabir Chakraborty (Jira)
Ranabir Chakraborty created WFLY-13282:
------------------------------------------
Summary: Remove unused dependencies from org.jboss.as.jpa
Key: WFLY-13282
URL: https://issues.redhat.com/browse/WFLY-13282
Project: WildFly
Issue Type: Sub-task
Components: Class Loading, JPA / Hibernate
Reporter: Ranabir Chakraborty
Assignee: Ranabir Chakraborty
Fix For: 20.0.0.Beta1
This issue folows up WFLY-11279. There are additional dependencies that can be removed from org.jboss.as.jpa.
The additional dependencies are:
* javax.annotation.api
* javax.resource.api
* javax.servlet.api
* org.jboss.common-beans
* org.jboss.threads
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month