[JBoss JIRA] (WFCORE-4192) Server-server EJB invocation fails if no security is defined on target bean due to faulty permission check
by Jiri Ondrusek (Jira)
[ https://issues.jboss.org/browse/WFCORE-4192?page=com.atlassian.jira.plugi... ]
Jiri Ondrusek moved JBEAP-15754 to WFCORE-4192:
-----------------------------------------------
Project: WildFly Core (was: JBoss Enterprise Application Platform)
Key: WFCORE-4192 (was: JBEAP-15754)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Security
(was: EJB)
(was: Security)
(was: Transactions)
Affects Version/s: 7.0.0.Alpha4
(was: 7.1.0.CR4)
> Server-server EJB invocation fails if no security is defined on target bean due to faulty permission check
> -----------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-4192
> URL: https://issues.jboss.org/browse/WFCORE-4192
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Affects Versions: 7.0.0.Alpha4
> Reporter: Jiri Ondrusek
> Assignee: Jiri Ondrusek
> Priority: Major
>
> Customer impact:
> Possibly in testing scenarios, production scenarios will very likely use security.
> Scenario description: Automated test ([source code|http://git.app.eng.bos.redhat.com/git/jbossqe/eap-tests-ejb.git/tree...]) which does these steps:
> 1. starts two servers (with standalone-ha.xml profile, but they don't form a cluster): CLUSTER1_NODE1 and CLUSTER2_NODE1 (the original scenario was simplified from 2 clusters to 2 servers)
> 2. creates remote outbound connection on CLUSTER1_NODE1 to CLUSTER2_NODE1:
> {code:xml}
> <subsystem xmlns="urn:jboss:domain:remoting:4.0">
> <endpoint/>
> <http-connector name="http-remoting-connector" connector-ref="default" security-realm="ApplicationRealm"/>
> <outbound-connections>
> <remote-outbound-connection name="connection-to-cluster2" outbound-socket-binding-ref="connection-to-cluster2"/>
> </outbound-connections>
> </subsystem>
> {code}
> 3. deletes security-realm="ApplicationRealm" from CLUSTER2_NODE1:
> {code:xml}
> <subsystem xmlns="urn:jboss:domain:remoting:4.0">
> <endpoint/>
> <http-connector connector-ref="default" name="http-remoting-connector"/>
> </subsystem>
> {code}
> 4. deploys intermediary bean on CLUSTER1_NODE1 ([source code|http://git.app.eng.bos.redhat.com/git/jbossqe/eap-tests-ejb.git/tree...]) and target bean on CLUSTER2_NODE1 ([source code|http://git.app.eng.bos.redhat.com/git/jbossqe/eap-tests-ejb.git/tree...])
> 5. invokes intermediary bean with this code:
> {code:java}
> final Properties properties = new Properties();
> properties.put(Context.INITIAL_CONTEXT_FACTORY, WildFlyInitialContextFactory.class.getName());
> final InitialContext ejbCtx = new InitialContext(properties);
> final IntermediaryBeanRemote bean = (IntermediaryBeanRemote)ejbCtx
> .lookup("ejb:/bean-intermediary/" + IntermediaryBeanStateless.class.getSimpleName() + "!"
> + IntermediaryBeanRemote.class.getName());
> for (int i = 0; i < 200; i++) {
> bean.call();
> }
> {code}
> When intermediary bean tries to invoke target bean, it gets this exception:
> {code}
> CLUSTER1_NODE1: 09:29:34,536 ERROR [org.jboss.as.ejb3.invocation] (default task-6) WFLYEJB0034: EJB Invocation failed on component IntermediaryBeanStateless for method public abstract void org.jboss.qa.ejb.tests.jbeap10217.beans.IntermediaryBeanRemote.call(): java.lang.SecurityException: WFTXN0013: The peer threw a SecurityException; see peer logs for more information
> at org.wildfly.transaction.client.provider.remoting.TransactionClientChannel.setRollbackOnly(TransactionClientChannel.java:178)
> at org.wildfly.transaction.client.provider.remoting.RemotingRemoteTransactionPeer$1.end(RemotingRemoteTransactionPeer.java:158)
> at org.wildfly.transaction.client.SubordinateXAResource.end(SubordinateXAResource.java:130)
> at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.doEnd(TransactionImple.java:1089)
> at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.endAssociation(TransactionImple.java:1060)
> at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.endAssociation(XAResourceRecord.java:1287)
> at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.topLevelAbort(XAResourceRecord.java:313)
> at com.arjuna.ats.arjuna.coordinator.BasicAction.doAbort(BasicAction.java:3023)
> at com.arjuna.ats.arjuna.coordinator.BasicAction.doAbort(BasicAction.java:3002)
> at com.arjuna.ats.arjuna.coordinator.BasicAction.Abort(BasicAction.java:1674)
> at com.arjuna.ats.arjuna.coordinator.BasicAction.Abort(BasicAction.java:1615)
> at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:99)
> at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162)
> at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1289)
> at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126)
> at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:89)
> at org.wildfly.transaction.client.LocalTransaction.commitAndDissociate(LocalTransaction.java:73)
> at org.wildfly.transaction.client.ContextTransactionManager.commit(ContextTransactionManager.java:71)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.endTransaction(CMTTxInterceptor.java:92)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:279)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:332)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:240)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:509)
> at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:73)
> at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:89)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:89)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:47)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:57)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:67)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:60)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:438)
> at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:609)
> at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:57)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:53)
> at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198)
> at org.jboss.as.ejb3.remote.AssociationImpl$$Lambda$1232/202321503.apply(Unknown Source)
> at org.wildfly.security.auth.server.SecurityIdentity.runAsFunctionEx(SecurityIdentity.java:380)
> at org.jboss.as.ejb3.remote.AssociationImpl.invokeWithIdentity(AssociationImpl.java:535)
> at org.jboss.as.ejb3.remote.AssociationImpl.invokeMethod(AssociationImpl.java:530)
> at org.jboss.as.ejb3.remote.AssociationImpl.lambda$receiveInvocationRequest$0(AssociationImpl.java:193)
> at org.jboss.as.ejb3.remote.AssociationImpl$$Lambda$1230/1343168004.run(Unknown Source)
> 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:745)
> Caused by: Remote exception java.lang.SecurityException: WFTXN0088: User anonymous does not have permission ("org.wildfly.transaction.client.RemoteTransactionPermission" "")
> at org.wildfly.transaction.client.provider.remoting.TransactionServerChannel.getSecurityIdentity(TransactionServerChannel.java:745)
> at org.wildfly.transaction.client.provider.remoting.TransactionServerChannel.handleXaTxnRollbackOnly(TransactionServerChannel.java:390)
> at org.wildfly.transaction.client.provider.remoting.TransactionServerChannel$ReceiverImpl.handleMessage(TransactionServerChannel.java:132)
> at org.jboss.remoting3.remote.RemoteConnectionChannel.lambda$handleMessageData$3(RemoteConnectionChannel.java:430)
> at org.jboss.remoting3.remote.RemoteConnectionChannel$$Lambda$901/21589536.run(Unknown Source)
> at org.jboss.remoting3.EndpointImpl$TrackingExecutor.lambda$execute$0(EndpointImpl.java:926)
> at org.jboss.remoting3.EndpointImpl$TrackingExecutor$$Lambda$885/1175809082.run(Unknown Source)
> ... 3 more
> {code}
> It seems, that transaction client is trying to check the "org.wildfly.transaction.client.RemoteTransactionPermission". This permission is bound to Elytron but Elytron is not running?
> The permission is defined in standalone-ha.xml on CLUSTER2_NODE1:
> {code:xml}
> <permission-mapping>
> <principal name="anonymous"/>
> <permission module="org.wildfly.extension.batch.jberet" target-name="*" class-name="org.wildfly.extension.batch.jberet.deployment.BatchPermission"/>
> <permission module="org.wildfly.transaction.client" class-name="org.wildfly.transaction.client.RemoteTransactionPermission"/>
> <permission module="org.jboss.ejb-client" class-name="org.jboss.ejb.client.RemoteEJBPermission"/>
> </permission-mapping>
> {code}
> Please check https://github.com/wildfly/wildfly-transaction-client/blob/master/src/mai...
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month
[JBoss JIRA] (WFLY-11178) WSTrustTestCase failing on IBM
by David Lloyd (Jira)
[ https://issues.jboss.org/browse/WFLY-11178?page=com.atlassian.jira.plugin... ]
David Lloyd commented on WFLY-11178:
------------------------------------
I believe there is no fix in JBoss Modules that will solve this. The property simply must not be set; setting the property results in undefined and unsupported behavior.
> WSTrustTestCase failing on IBM
> ------------------------------
>
> Key: WFLY-11178
> URL: https://issues.jboss.org/browse/WFLY-11178
> Project: WildFly
> Issue Type: Bug
> Components: MSC
> Affects Versions: 14.0.0.Final
> Reporter: Jan Blizňák
> Assignee: Alessio Soldano
> Priority: Major
> Attachments: log.txt
>
>
> As discovered during investigation in WFLY-10336, we are now getting test failures in WSTrustTestCase when IBM JDK is used. The relevant part of the exception is:
> {code:java}
> Caused by: java.lang.IllegalArgumentException: Provider org.apache.xerces.jaxp.validation.XMLSchemaFactory not found
> at javax.xml.validation.SchemaFactory.newInstance(Unknown Source)
> at org.opensaml.core.xml.config.XMLConfigurator.<init>(XMLConfigurator.java:94)
> at org.apache.wss4j.common.saml.OpenSAMLBootstrap.bootstrap(OpenSAMLBootstrap.java:85)
> at org.apache.wss4j.common.saml.OpenSAMLUtil.initSamlEngine(OpenSAMLUtil.java:91)
> at org.apache.wss4j.common.saml.OpenSAMLUtil.initSamlEngine(OpenSAMLUtil.java:75)
> at org.apache.wss4j.common.saml.SamlAssertionWrapper.<init>(SamlAssertionWrapper.java:184)
> at org.apache.cxf.sts.token.provider.SAMLTokenProvider.createSamlToken(SAMLTokenProvider.java:308)
> at org.apache.cxf.sts.token.provider.SAMLTokenProvider.createToken(SAMLTokenProvider.java:120)
> ... 102 more
> {code}
> It turned out the issue is in wildfly for some time, the breaking change was identified as https://github.com/wildfly/wildfly-core/pull/3201/
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month
[JBoss JIRA] (WFLY-11178) WSTrustTestCase failing on IBM
by Martin Švehla (Jira)
[ https://issues.jboss.org/browse/WFLY-11178?page=com.atlassian.jira.plugin... ]
Martin Švehla updated WFLY-11178:
---------------------------------
Tester: Michal Jurc
> WSTrustTestCase failing on IBM
> ------------------------------
>
> Key: WFLY-11178
> URL: https://issues.jboss.org/browse/WFLY-11178
> Project: WildFly
> Issue Type: Bug
> Components: MSC
> Affects Versions: 14.0.0.Final
> Reporter: Jan Blizňák
> Assignee: Alessio Soldano
> Priority: Major
> Attachments: log.txt
>
>
> As discovered during investigation in WFLY-10336, we are now getting test failures in WSTrustTestCase when IBM JDK is used. The relevant part of the exception is:
> {code:java}
> Caused by: java.lang.IllegalArgumentException: Provider org.apache.xerces.jaxp.validation.XMLSchemaFactory not found
> at javax.xml.validation.SchemaFactory.newInstance(Unknown Source)
> at org.opensaml.core.xml.config.XMLConfigurator.<init>(XMLConfigurator.java:94)
> at org.apache.wss4j.common.saml.OpenSAMLBootstrap.bootstrap(OpenSAMLBootstrap.java:85)
> at org.apache.wss4j.common.saml.OpenSAMLUtil.initSamlEngine(OpenSAMLUtil.java:91)
> at org.apache.wss4j.common.saml.OpenSAMLUtil.initSamlEngine(OpenSAMLUtil.java:75)
> at org.apache.wss4j.common.saml.SamlAssertionWrapper.<init>(SamlAssertionWrapper.java:184)
> at org.apache.cxf.sts.token.provider.SAMLTokenProvider.createSamlToken(SAMLTokenProvider.java:308)
> at org.apache.cxf.sts.token.provider.SAMLTokenProvider.createToken(SAMLTokenProvider.java:120)
> ... 102 more
> {code}
> It turned out the issue is in wildfly for some time, the breaking change was identified as https://github.com/wildfly/wildfly-core/pull/3201/
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month
[JBoss JIRA] (WFLY-11178) WSTrustTestCase failing on IBM
by Jan Blizňák (Jira)
[ https://issues.jboss.org/browse/WFLY-11178?page=com.atlassian.jira.plugin... ]
Jan Blizňák updated WFLY-11178:
-------------------------------
Component/s: MSC
(was: Web Services)
Steps to Reproduce:
{code:java}
#build wildfly
mvn clean install -DskipTests
#run tests
mvn verify -pl testsuite/integration/ws -Dts.basic -Dtest=WSTrustTestCase -DtestLogToFile=false
{code}
was:
{code:java}
#build wildfly
mvn clean install -DskipTests
#run tests
mvn verify -pl testsuite/integration/ws -Dts.basic -Dtest=WSTrustTestCase -DtestLogToFile=false
{code}
As shown by reproducer, the root problem isn't in Webservices, changing component to modules.
> WSTrustTestCase failing on IBM
> ------------------------------
>
> Key: WFLY-11178
> URL: https://issues.jboss.org/browse/WFLY-11178
> Project: WildFly
> Issue Type: Bug
> Components: MSC
> Affects Versions: 14.0.0.Final
> Reporter: Jan Blizňák
> Assignee: Alessio Soldano
> Priority: Major
> Attachments: log.txt
>
>
> As discovered during investigation in WFLY-10336, we are now getting test failures in WSTrustTestCase when IBM JDK is used. The relevant part of the exception is:
> {code:java}
> Caused by: java.lang.IllegalArgumentException: Provider org.apache.xerces.jaxp.validation.XMLSchemaFactory not found
> at javax.xml.validation.SchemaFactory.newInstance(Unknown Source)
> at org.opensaml.core.xml.config.XMLConfigurator.<init>(XMLConfigurator.java:94)
> at org.apache.wss4j.common.saml.OpenSAMLBootstrap.bootstrap(OpenSAMLBootstrap.java:85)
> at org.apache.wss4j.common.saml.OpenSAMLUtil.initSamlEngine(OpenSAMLUtil.java:91)
> at org.apache.wss4j.common.saml.OpenSAMLUtil.initSamlEngine(OpenSAMLUtil.java:75)
> at org.apache.wss4j.common.saml.SamlAssertionWrapper.<init>(SamlAssertionWrapper.java:184)
> at org.apache.cxf.sts.token.provider.SAMLTokenProvider.createSamlToken(SAMLTokenProvider.java:308)
> at org.apache.cxf.sts.token.provider.SAMLTokenProvider.createToken(SAMLTokenProvider.java:120)
> ... 102 more
> {code}
> It turned out the issue is in wildfly for some time, the breaking change was identified as https://github.com/wildfly/wildfly-core/pull/3201/
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month
[JBoss JIRA] (DROOLS-3193) UX to support selection of multiple data/domain object instances
by Edson Tirelli (Jira)
[ https://issues.jboss.org/browse/DROOLS-3193?page=com.atlassian.jira.plugi... ]
Edson Tirelli commented on DROOLS-3193:
---------------------------------------
{quote}Regarding the last image you posted, in the current implementation, it is not possible to achieve it (all columns whose instance type is Dispute would get merged together, so there would be only one header row called Dispute and the header row below would be divided into six columns as in the image). You need to introduce an alias to create this structure (such as First dispute, Second dispute, Third dispute). But otherwise, it is a valid grid.{quote}
This limitation is fine for now, but we should plan to remove it in the future. From a semantic perspective, it is fine to have multiple anonymous instances of the same type.
> UX to support selection of multiple data/domain object instances
> ----------------------------------------------------------------
>
> Key: DROOLS-3193
> URL: https://issues.jboss.org/browse/DROOLS-3193
> Project: Drools
> Issue Type: Task
> Components: Scenario Simulation and Testing
> Reporter: Liz Clayton
> Assignee: Liz Clayton
> Priority: Major
> Labels: ScenarioSimulation, UX, UXTeam
> Attachments: Screen Shot 2018-10-30 at 10.50.55 AM.png
>
>
> As user I want to use multiple instances of the same data object in my test scenarios (multiple instances support) (i.e. scenario with more than one instance of “Person”...), so that I can create a test scenario.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month
[JBoss JIRA] (SWSQE-476) PRT Output Improve
by Hayk Hovsepyan (Jira)
Hayk Hovsepyan created SWSQE-476:
------------------------------------
Summary: PRT Output Improve
Key: SWSQE-476
URL: https://issues.jboss.org/browse/SWSQE-476
Project: Kiali QE
Issue Type: QE Task
Reporter: Hayk Hovsepyan
Assignee: Hayk Hovsepyan
Feedback from developers.
When PRT fails because of some internal reason, e.g. bookinfo install fails, devs are confused. Or if e2e tests fail for some other reason.
What we need to do, when PRT fails due to other reason that e2e tests broken by PR, then the bot should comment in PR that "PRT is broken, contact to QE".
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month
[JBoss JIRA] (DROOLS-3193) UX to support selection of multiple data/domain object instances
by Liz Clayton (Jira)
[ https://issues.jboss.org/browse/DROOLS-3193?page=com.atlassian.jira.plugi... ]
Liz Clayton commented on DROOLS-3193:
-------------------------------------
[~kkufova] Thanks for the information.
* I'm working on designs for potential future implementations. So trying to scope out things like reordering columns/rows and etc.
* Regarding the spanning header, that gets to the point of one of my questions - how do we distinguish different instances for the user (by name/nickname, ID, column position, etc.)
> UX to support selection of multiple data/domain object instances
> ----------------------------------------------------------------
>
> Key: DROOLS-3193
> URL: https://issues.jboss.org/browse/DROOLS-3193
> Project: Drools
> Issue Type: Task
> Components: Scenario Simulation and Testing
> Reporter: Liz Clayton
> Assignee: Liz Clayton
> Priority: Major
> Labels: ScenarioSimulation, UX, UXTeam
> Attachments: Screen Shot 2018-10-30 at 10.50.55 AM.png
>
>
> As user I want to use multiple instances of the same data object in my test scenarios (multiple instances support) (i.e. scenario with more than one instance of “Person”...), so that I can create a test scenario.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month