[JBoss JIRA] (WFLY-7161) EJB with defined specific security domain which is different than the one used for undertow fails when using with elytron
by Radim Hatlapatka (JIRA)
Radim Hatlapatka created WFLY-7161:
--------------------------------------
Summary: EJB with defined specific security domain which is different than the one used for undertow fails when using with elytron
Key: WFLY-7161
URL: https://issues.jboss.org/browse/WFLY-7161
Project: WildFly
Issue Type: Bug
Components: Security
Reporter: Radim Hatlapatka
Assignee: Darran Lofthouse
Priority: Critical
When having deployment with EJB which is invoked from servlet and the EJB has defined specific security domain to use via {{@SecurityDomain}} annotation, the ejb method invocation fails when there is defined elytron security domain for undertow and old security domain for EJBs with \[1\].
Note when having both security domains setup only using old security subsystems, the access is allowed as expected.
Marking as critical as this should work. If it is not considered supported use case then there should be at least shown proper warning in logs explaining what is wrong.
\[1\]
{noformat}
09:30:03,749 ERROR [org.jboss.as.ejb3.invocation] (default task-25) WFLYEJB0034: EJB Invocation failed on component SecuredEjb for method public java.lang.String org.jboss.qa.management.web.resources.SecuredEjb.securedText(): javax.ejb.EJBAccessException: WFLYEJB0364: Invocation on method: public java.lang.String org.jboss.qa.management.web.resources.SecuredEjb.securedText() of bean: SecuredEjb is not allowed
at org.jboss.as.ejb3.security.AuthorizationInterceptor.processInvocation(AuthorizationInterceptor.java:134)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359)
at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359)
at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359)
at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359)
at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:67)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359)
at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359)
at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359)
at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359)
at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:375)
at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:609)
at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359)
at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:375)
at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359)
at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198)
at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:185)
at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:74)
at org.jboss.qa.management.web.resources.SecuredEjb$$$view6.securedText(Unknown Source)
at org.jboss.qa.management.web.resources.ServletWithSecuredEjb.doGet(ServletWithSecuredEjb.java:27)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
at org.wildfly.elytron.web.undertow.server.ElytronRunAsHandler.lambda$handleRequest$0(ElytronRunAsHandler.java:56)
at org.wildfly.security.auth.client.PeerIdentity.runAsAll(PeerIdentity.java:395)
at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:188)
at org.wildfly.elytron.web.undertow.server.ElytronRunAsHandler.handleRequest(ElytronRunAsHandler.java:55)
at io.undertow.server.handlers.BlockingHandler.handleRequest(BlockingHandler.java:56)
at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53)
at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59)
at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1668)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1668)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1668)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1668)
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:207)
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:810)
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)
{noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (WFLY-7140) Injection with @EJB is not working as expected with CDI (REST) beans
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-7140?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration updated WFLY-7140:
------------------------------------------
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1377705
Bugzilla Update: Perform
> Injection with @EJB is not working as expected with CDI (REST) beans
> --------------------------------------------------------------------
>
> Key: WFLY-7140
> URL: https://issues.jboss.org/browse/WFLY-7140
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, EJB
> Reporter: Wolf-Dieter Fink
> Assignee: Jason Greene
>
> The injection with @EJB should work the same way in a Rest service (CDI Bean) as it does in a Servlet.
> @EJB(lookup = "ejb:jboss-ejb-multi-server-app-one/ejb/AppOneBean!org.jboss.as.quickstarts.ejb.multi.server.app.AppOne")
> is not working correct if used in a CDI Bean in the reproducer example.
> Reproducer can be found here:
> git@github.com:wfink/jboss-eap-quickstarts.git
> BRANCH: 6.4.x_ejb-multi-server_reproducerEJB-injection
> SubProject: ejb-multi-server (used only a part of it to have a web-app and a ejb-app)
> see ejb-multi-server/README-reproducerEJB-injection
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (WFLY-7159) Too complex Elytron Domain Model
by Ondrej Lukas (JIRA)
Ondrej Lukas created WFLY-7159:
----------------------------------
Summary: Too complex Elytron Domain Model
Key: WFLY-7159
URL: https://issues.jboss.org/browse/WFLY-7159
Project: WildFly
Issue Type: Bug
Components: Security
Reporter: Ondrej Lukas
Assignee: Darran Lofthouse
Priority: Critical
User experience with Elytron domain model is sub-optimal.
It's hard to define correctly complex attributes in the Elytron Subsystem configuration. It's much simpler to write the CLI with primitive attributes instead. Also the Management console is not able to generate forms for complex-types automatically.
1) Domain model of subsystem is too flat. Every resource (realms, mappers, factories ...) is located at the base level of Elytron subsystem. Then it is hard to orientate in subsystem since it does not have deeper structure.
Suggestion:
It can be structuralized similar as PicketBox subsystem. There could be some subresources like realms, domains etc.
2) Elytron subsystem contains a lot of complex types which strongly complicate setting of attributes for resources. It mainly affects
* {{add}} operation - there is insufficient support from CLI since tab button not sufficiently works. It is also non-intuitive and error-prone when all setting is mixed to one difficult command.
* {{write-attribute}} operation - using write-attribute for some values from complex inner attribute is really hard - e.g. set particular value for some inner attribute of complex object stored in list.
It is different aproach than most of other subsystems uses.
Suggestion:
Replace complex attributes with child resources.
This could be also discussed with UX team. Once this domain model will be released in WildFly/EAP then it will be very hard to rewrite it do to backward compatibility.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (WFLY-7158) Working with multiple keys in key store
by Martin Choma (JIRA)
[ https://issues.jboss.org/browse/WFLY-7158?page=com.atlassian.jira.plugin.... ]
Martin Choma moved JBEAP-6099 to WFLY-7158:
-------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-7158 (was: JBEAP-6099)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Security
(was: Security)
Affects Version/s: 11.0.0.Alpha1
(was: 7.1.0.DR5)
> Working with multiple keys in key store
> ---------------------------------------
>
> Key: WFLY-7158
> URL: https://issues.jboss.org/browse/WFLY-7158
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Martin Choma
> Assignee: Darran Lofthouse
> Priority: Critical
>
> In case when 2 keys are present in keystore, then alias-filter (filtering into single key) on key-store resource has to be specified, otherwise key-manager can't be created. If user want to use keystore with multiple keys, user has to configure multiple key-store elements with specified alias-filter (filtering into single key).
> That is pretty inconvinient. Probably introducing alias attribute on key-manager would be more intuitive solution to this situation.
> {code}
> /subsystem=elytron/key-managers=server:add(key-store=server,algorithm="SunX509",password=key-password)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (DROOLS-987) Errors in Phreak under heavy and multi threaded load
by Edson Tirelli (JIRA)
[ https://issues.jboss.org/browse/DROOLS-987?page=com.atlassian.jira.plugin... ]
Edson Tirelli reassigned DROOLS-987:
------------------------------------
Assignee: Maciej Swiderski (was: Marco Rietveld)
> Errors in Phreak under heavy and multi threaded load
> -----------------------------------------------------
>
> Key: DROOLS-987
> URL: https://issues.jboss.org/browse/DROOLS-987
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.3.0.Final, 6.4.0.Final
> Environment: linux
> Java 7
> kernel 3.16
> Reporter: Jose Cavieres
> Assignee: Maciej Swiderski
> Attachments: jbpm-bussinesruletask-concurrent-6-3-NEW.tgz, jbpm-bussinesruletask-concurrent-6-3.tgz
>
>
> Several threads are started, each one starts 1 jbpm process containing rule(s) task(s).
> If the threads are few, everything works fine. Under heavy load nullPointerExceptions are thown most of the time, less frequently fireAllRules never ends and CPU remains at 100%.
> Aparently the setFocus method used by rule tasks is related to the problem.
> The most comon error is:
> Caused by: java.lang.NullPointerException
> at org.drools.core.common.LeftTupleSetsImpl.removeInsert(LeftTupleSetsImpl.java:141)
> at org.drools.core.common.LeftTupleSetsImpl.addDelete(LeftTupleSetsImpl.java:80)
> at org.drools.core.reteoo.LeftInputAdapterNode.doDeleteSegmentMemory(LeftInputAdapterNode.java:295)
> at org.drools.core.reteoo.LeftInputAdapterNode.doDeleteObject(LeftInputAdapterNode.java:266)
> at org.drools.core.reteoo.LeftInputAdapterNode.retractLeftTuple(LeftInputAdapterNode.java:361)
> at org.drools.core.reteoo.ObjectTypeNode.doRetractObject(ObjectTypeNode.java:334)
> at org.drools.core.reteoo.ObjectTypeNode.retractObject(ObjectTypeNode.java:317)
> at org.drools.core.reteoo.EntryPointNode.propagateRetract(EntryPointNode.java:358)
> at org.drools.core.phreak.PropagationEntry$Delete.execute(PropagationEntry.java:172)
> at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:96)
> at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:69)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.flushPropagations(StatefulKnowledgeSessionImpl.java:1993)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (WFLY-7157) Audit @Ignore-d clustering integration tests
by Radoslav Husar (JIRA)
Radoslav Husar created WFLY-7157:
------------------------------------
Summary: Audit @Ignore-d clustering integration tests
Key: WFLY-7157
URL: https://issues.jboss.org/browse/WFLY-7157
Project: WildFly
Issue Type: Task
Components: Clustering
Affects Versions: 10.1.0.CR1
Reporter: Radoslav Husar
Assignee: Radoslav Husar
Fix For: 11.0.0.Alpha1
Recently stumbling upon an @Ignore-d test which would have caught a regression, we need to audit ignored clustering tests, e.g. some are referencing already fixed issues.
{noformat}
[rhusar@syrah clustering]$ git grep @Ignore
src/test/java/org/jboss/as/test/clustering/cluster/ejb/remote/RemoteFailoverTestCase.java: @Ignore("WFLY-3532")
src/test/java/org/jboss/as/test/clustering/cluster/ejb/stateful/StatefulFailoverTestCase.java: @Ignore("WFLY-835 @Resource UserTransaction error when file passivation store is selected")
src/test/java/org/jboss/as/test/clustering/cluster/web/passivation/CoarseSessionPassivationTestCase.java:@Ignore("WFLY-6624")
src/test/java/org/jboss/as/test/clustering/cluster/web/passivation/FineSessionPassivationTestCase.java:@Ignore("WFLY-6624")
src/test/java/org/jboss/as/test/clustering/extended/ejb2/stateful/passivation/ClusterPassivationTestCase.java: @Ignore("JBPAPP-8774")
src/test/java/org/jboss/as/test/clustering/extended/ejb2/stateful/remote/failover/dd/RemoteEJB2ClientStatefulBeanFailoverDDTestCase.java: @Ignore("JBPAPP-8726")
src/test/java/org/jboss/as/test/clustering/extended/ejb2/stateful/remote/failover/dd/RemoteEJB2ClientStatefulBeanFailoverDDTestCase.java: @Ignore("JBPAPP-8726")
src/test/java/org/jboss/as/test/clustering/single/jdbcstore/TransactionalJdbcStoreTestCase.java:@Ignore("https://issues.jboss.org/browse/ISPN-604")
src/test/java/org/jboss/as/test/clustering/xsite/XSiteSimpleTestCase.java: @Ignore("https://issues.jboss.org/browse/WFLY-5239")
{noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months