[JBoss JIRA] (WFLY-7163) Relative ordering of webfragments causes an IllegalStateException
by Sverre Boschman (JIRA)
Sverre Boschman created WFLY-7163:
-------------------------------------
Summary: Relative ordering of webfragments causes an IllegalStateException
Key: WFLY-7163
URL: https://issues.jboss.org/browse/WFLY-7163
Project: WildFly
Issue Type: Bug
Components: Web (Undertow)
Affects Versions: 9.0.2.Final, 11.0.0.Alpha1
Environment: Issue found on 9.0.2; testcase made against master (11.0.0.Alpha1-SNAPSHOT)
Reporter: Sverre Boschman
Assignee: Stuart Douglas
Priority: Minor
Attachments: undertow_webfragment_test.zip
Caused by: java.lang.IllegalStateException: WFLYUT0047: Relative ordering conflict with JAR: <jarname>.jar
at org.wildfly.extension.undertow.deployment.WarMetaDataProcessor.resolveOrder(WarMetaDataProcessor.java:717)
at org.wildfly.extension.undertow.deployment.WarMetaDataProcessor.deploy(WarMetaDataProcessor.java:212)
... 6 more
--
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 Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-7159?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse resolved WFLY-7159.
------------------------------------
Fix Version/s: 11.0.0.Alpha1
Resolution: Rejected
I am rejecting this on the basis that it is too broad.
There are valid points in here so I recommend individual issues for the individual concerns so we can address them all individually, not all issues raised automatically point to refactoring a single subsystem.
> 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
> Fix For: 11.0.0.Alpha1
>
>
> 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] (DROOLS-1300) result of rule execution in STREAM mode are different between PHREAK and RETEOO
by Hiroko Miura (JIRA)
Hiroko Miura created DROOLS-1300:
------------------------------------
Summary: result of rule execution in STREAM mode are different between PHREAK and RETEOO
Key: DROOLS-1300
URL: https://issues.jboss.org/browse/DROOLS-1300
Project: Drools
Issue Type: Bug
Components: core engine
Affects Versions: 6.4.0.Final
Reporter: Hiroko Miura
Assignee: Mario Fusco
Priority: Critical
Fix For: 6.5.0.Final
Attachments: rules-reproducer.zip
Customer is developing rules and runs it as CEP in STREAM mode.
When executing it with same facts , the results (remaining objects in working memory) are
different between PHREAK and RETEOO.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[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 Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-7161?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse updated WFLY-7161:
-----------------------------------
Priority: Major (was: Critical)
> 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
>
> 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-7159) Too complex Elytron Domain Model
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-7159?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse updated WFLY-7159:
-----------------------------------
Priority: Major (was: Critical)
> 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
>
> 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-7143) Unsafe Elytron role/permission mapping
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFLY-7143?page=com.atlassian.jira.plugin.... ]
Jan Kalina commented on WFLY-7143:
----------------------------------
Yes, add constant-permission-mapper sounds much better then to have part of permission as blacklist (LoginPermission) and part as whitelist (others).
> Unsafe Elytron role/permission mapping
> --------------------------------------
>
> Key: WFLY-7143
> URL: https://issues.jboss.org/browse/WFLY-7143
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Josef Cacek
> Assignee: Jan Kalina
> Priority: Blocker
>
> Default Elytron configuration assigns role "All" to every user during authentication. If a deployed application uses such the role name for a resource protection, then every authenticated user can access the protected resource. So the security is bypassed then.
> The problem is caused by workaround used for mapping "LoginPermission" to all users. It maps role "All" to the users first and then maps "LoginPermission" to this role.
> {code:xml}
> <mappers>
> <simple-permission-mapper name="login-permission-mapper">
> <permission-mapping roles="All">
> <permission class-name="org.wildfly.security.auth.permission.LoginPermission"/>
> </permission-mapping>
> </simple-permission-mapper>
> <constant-role-mapper name="constant-roles" roles="All"/>
> </mappers>
> {code}
> We have to make the default server configuration secure for users.
> *Suggestions for improvement:*
> * the {{LoginPermission}} mapping should be implicit so everybody has it by default - without specifying it in the server configuration; users should only define cases when they don't want the permission to be assigned to some principals/roles
> * constant permission mapper should exist in Elytron subsystem (similar to {{constant-role-mapper}}) so the custom permission can be mapped without workarounds through role-mappings
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (WFLY-7162) Elytron filtering-key-store:write-attribute cause NPE
by Martin Choma (JIRA)
[ https://issues.jboss.org/browse/WFLY-7162?page=com.atlassian.jira.plugin.... ]
Martin Choma moved JBEAP-6105 to WFLY-7162:
-------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-7162 (was: JBEAP-6105)
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)
> Elytron filtering-key-store:write-attribute cause NPE
> -----------------------------------------------------
>
> Key: WFLY-7162
> URL: https://issues.jboss.org/browse/WFLY-7162
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Martin Choma
> Assignee: Darran Lofthouse
> Priority: Critical
>
> Trying to update filtering-key-store cause NPE
> {code}
> [standalone@localhost:9990 /] /subsystem=elytron/filtering-key-store=filteringKeyStore:add(key-store=server, alias-filter=undertow)
> {"outcome" => "success"}
> [standalone@localhost:9990 /] /subsystem=elytron/filtering-key-store=filteringKeyStore:write-attribute(name=alias-filter,value=management)
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.NullPointerException",
> "rolled-back" => true
> }
> {code}
> Stacktrace:
> {code}
> 09:51:45,250 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 10) WFLYCTL0013: Operation ("write-attribute") failed - address: ([
> ("subsystem" => "elytron"),
> ("filtering-key-store" => "filteringKeyStore")
> ]): java.lang.NullPointerException
> at org.wildfly.extension.elytron.FilteringKeyStoreDefinition$WriteAttributeHandler.getParentServiceName(FilteringKeyStoreDefinition.java:174)
> at org.jboss.as.controller.RestartParentWriteAttributeHandler.applyUpdateToRuntime(RestartParentWriteAttributeHandler.java:57)
> at org.jboss.as.controller.AbstractWriteAttributeHandler$1.execute(AbstractWriteAttributeHandler.java:104)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:940)
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:683)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:382)
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1363)
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:410)
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:232)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:213)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:136)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:153)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:422)
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:149)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153)
> at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70)
> at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160)
> 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)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> {code}
--
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 Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/WFLY-7140?page=com.atlassian.jira.plugin.... ]
Martin Kouba commented on WFLY-7140:
------------------------------------
For the record, {{org.jboss.as.weld.services.bootstrap.WeldEjbInjectionServices}} (responsible for @EJB injection) is using {{org.jboss.as.naming.deployment.ContextNames}} which obviously does not support this jboss-specific "ejb" namespace. So the only solution I see is to detect this namespace and perform a simple {{new InitialContext().lookup(name)}}.
> 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