[JBoss JIRA] (WFLY-9469) Assumes in SPNEGOLoginModuleTestCase doen's make sense
by Romain Pelisse (JIRA)
Romain Pelisse created WFLY-9469:
------------------------------------
Summary: Assumes in SPNEGOLoginModuleTestCase doen's make sense
Key: WFLY-9469
URL: https://issues.jboss.org/browse/WFLY-9469
Project: WildFly
Issue Type: Bug
Components: Test Suite
Reporter: Romain Pelisse
Priority: Minor
Assumes in SPNEGOLoginModuleTestCase doen's make sense.
AssumeKerberosAuthenticationSupported is called in @Before method. Same method is called in many test methods:
testIdentityPropagation
testFormFallback
testSimpleSpnegoWorkflow
testMoreMechTypesSpnegoWorkflow
assumeKerberosAuthenticationSupported method from KerberosTestUtils.java shouldn't contains assume for BZ1188632, because BZ1188632 is fixed (works correctly with new version of IBM JDK).
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 8 months
[JBoss JIRA] (WFLY-9468) WFLYTX0001: Unable to roll back active transaction thrown for EJB bridge transactions
by Ondra Chaloupka (JIRA)
Ondra Chaloupka created WFLY-9468:
-------------------------------------
Summary: WFLYTX0001: Unable to roll back active transaction thrown for EJB bridge transactions
Key: WFLY-9468
URL: https://issues.jboss.org/browse/WFLY-9468
Project: WildFly
Issue Type: Bug
Components: XTS
Affects Versions: 11.0.0.CR1
Reporter: Ondra Chaloupka
Assignee: Ondra Chaloupka
It happens to get exception
{code}
ERROR [org.jboss.as.txn] (default task-12) WFLYTX0003: APPLICATION ERROR: transaction still active in request with status 0
ERROR [org.jboss.as.txn] (default task-12) 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:100)
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:1510)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:326)
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:812)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
{code}
when using XTS transactions bridged to JTA for EJB handling. This happens on change of integration layer for WFTC in WFLY11.
The integration issues were already discussed as part of the JBTM-2853.
Here I hit a trouble of having log filled with the exception mentioned above. This does not cause a functionality trouble but the log is ugly filled with ERRORs.
The trouble seems to be caused by the fact that transaction is imported on ivocation of WS
https://github.com/wildfly/wildfly/blob/master/webservices/server-integra...
but as it was suspended in the integration code before
https://github.com/jbosstm/narayana/blob/master/txbridge/src/main/java/or...
now the WFTC holds the notion about the transaction even on call of
https://github.com/wildfly/wildfly/blob/master/transactions/src/main/java...
and such transaction is tried to be rollback which is forbidden on WFTC for imported ones and thus at least ERROR msg is written to the log.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 8 months
[JBoss JIRA] (WFLY-447) Connection Reauthentication and Security Propagation
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-447?page=com.atlassian.jira.plugin.s... ]
Jason Greene updated WFLY-447:
------------------------------
Fix Version/s: 12.0.0.Alpha1
(was: 11.0.0.Final)
> Connection Reauthentication and Security Propagation
> ----------------------------------------------------
>
> Key: WFLY-447
> URL: https://issues.jboss.org/browse/WFLY-447
> Project: WildFly
> Issue Type: Task
> Components: EJB, Remoting, Security
> Reporter: Darran Lofthouse
> Labels: authentication_service
> Fix For: 12.0.0.Alpha1
>
>
> This task is a top level task to coordinate the addition of support for switching to different security identities on an existing connection over Remoting.
> This is to predominantly cover two major scenarios: -
> - Clients using a single connection but require different calls to be executed as different users, in this case the client has the information required to start a new authentication as a different user.
> - Server to server communication where the first server has already authenticated a remote user - for this scenario the first server needs a way to tell the second server what identity to run the call as.
> The following document is building up the requirements and design considerations and decisions: -
> https://community.jboss.org/wiki/ConnectionRe-AuthenticationAndSecurityPr...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 8 months
[JBoss JIRA] (WFLY-466) Detect JBossWS Configuration for @PermitAll endpoints within Undertow subsystem.
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-466?page=com.atlassian.jira.plugin.s... ]
Jason Greene updated WFLY-466:
------------------------------
Fix Version/s: 12.0.0.Alpha1
(was: 11.0.0.Final)
> Detect JBossWS Configuration for @PermitAll endpoints within Undertow subsystem.
> --------------------------------------------------------------------------------
>
> Key: WFLY-466
> URL: https://issues.jboss.org/browse/WFLY-466
> Project: WildFly
> Issue Type: Task
> Components: Web (Undertow)
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Fix For: 12.0.0.Alpha1
>
>
> UNDERTOW-38 has added the possibility of deploying web applications where authentication is mandated but no authorization checks are performed - this is required for integration use cases such as EJB endpoints where authorization checks are being left to the EJB container.
> This task is to update the Undertow susbsystem to detect this scenario and enable the new mode for UNDERTOW-38.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 8 months
[JBoss JIRA] (WFLY-2102) Improve deployment annotation parsing error message
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-2102?page=com.atlassian.jira.plugin.... ]
Jason Greene updated WFLY-2102:
-------------------------------
Fix Version/s: 12.0.0.Alpha1
(was: 11.0.0.Final)
> Improve deployment annotation parsing error message
> -----------------------------------------------------
>
> Key: WFLY-2102
> URL: https://issues.jboss.org/browse/WFLY-2102
> Project: WildFly
> Issue Type: Enhancement
> Components: EE
> Reporter: Brad Maxwell
> Fix For: 12.0.0.Alpha1
>
> Attachments: test-WFLY-2102.jar
>
>
> Improve deployment annotation parsing error message
> Code such as this below, will error with IllegalArgumentException: Empty name segment is not allowed for env. The env is not enough information to identify what the issue is.
> @Singleton
> @Startup
> public class TestEJB {
> @Resource(name="/queue/test")
> private Queue queue;
> }
> Caused by: java.lang.IllegalArgumentException: Empty name segment is not allowed for env
> at org.jboss.msc.service.ServiceName.of(ServiceName.java:85) [jboss-msc-1.0.4.GA-redhat-1.jar:1.0.4.GA-redhat-1]
> at org.jboss.msc.service.ServiceName.append(ServiceName.java:112) [jboss-msc-1.0.4.GA-redhat-1.jar:1.0.4.GA-redhat-1]
> at org.jboss.as.naming.deployment.ContextNames.buildServiceName(ContextNames.java:183)
> at org.jboss.as.naming.deployment.ContextNames$BindInfo.<init>(ContextNames.java:195)
> at org.jboss.as.naming.deployment.ContextNames$BindInfo.<init>(ContextNames.java:186)
> at org.jboss.as.naming.deployment.ContextNames.bindInfoFor(ContextNames.java:141)
> at org.jboss.as.ee.component.OptionalLookupInjectionSource.getResourceValue(OptionalLookupInjectionSource.java:84)
> at org.jboss.as.ee.component.ComponentDescription$InjectedConfigurator.configureDependency(ComponentDescription.java:1019)
> at org.jboss.as.ee.component.ComponentDescription$InjectedConfigurator.configureDependency(ComponentDescription.java:998)
> at org.jboss.as.ee.component.deployers.ComponentInstallProcessor.deployComponent(ComponentInstallProcessor.java:138)
> at org.jboss.as.ee.component.deployers.ComponentInstallProcessor.deploy(ComponentInstallProcessor.java:95)
> ... 6 more
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 8 months
[JBoss JIRA] (WFLY-1598) Out of the box SSL - or shortly after.
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-1598?page=com.atlassian.jira.plugin.... ]
Jason Greene updated WFLY-1598:
-------------------------------
Fix Version/s: 12.0.0.Alpha1
(was: 11.0.0.Final)
> Out of the box SSL - or shortly after.
> --------------------------------------
>
> Key: WFLY-1598
> URL: https://issues.jboss.org/browse/WFLY-1598
> Project: WildFly
> Issue Type: Sub-task
> Components: Domain Management, Security
> Reporter: Darran Lofthouse
> Priority: Critical
> Labels: management_security,, management_sso
> Fix For: 12.0.0.Alpha1
>
>
> There are various reasons that we do not support SSL/TLS out of the box e.g.
> - If we ship a default keystore then everyone has access to the private key.
> - Generating one on first boot we do not have sufficient information to generate it correctly, also the performance overhead.
> This issue is to explorer other options to encourage their use and make it easier to configure.
> As an example could the admin console detect a non encrypted connection and have an box that encourages the config along with a wizard like workflow to get it set up?
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 8 months