[JBoss JIRA] (WFCORE-4869) Cannot configure Elytron legacy security domain integration in admin-only mode
by Yeray Borges Santana (Jira)
Yeray Borges Santana created WFCORE-4869:
--------------------------------------------
Summary: Cannot configure Elytron legacy security domain integration in admin-only mode
Key: WFCORE-4869
URL: https://issues.redhat.com/browse/WFCORE-4869
Project: WildFly Core
Issue Type: Bug
Affects Versions: 10.0.0.Beta2
Reporter: Yeray Borges Santana
Assignee: Yeray Borges Santana
The following sequence can be configured using the embedded server, however it doesn't work when we start the server in admin only:
{noformat}
/subsystem=security/security-domain=HiThere:add(cache-type=default)
/subsystem=security/security-domain=HiThere/authentication=classic:add(login-modules=[{code="UsersRoles", flag=required, module-options={"usersProperties"=>"${jboss.server.config.dir}/users.properties","rolesProperties"=>"${jboss.server.config.dir}/roles.properties"}}])
/subsystem=security/elytron-realm=HiThere:add(legacy-jaas-config=HiThere)
/subsystem=elytron/security-domain=HiThere:add(realms=[{realm=HiThere}],default-realm=HiThere,permission-mapper=default-permission-mapper)
/subsystem=elytron/http-authentication-factory=HiThere-http:add(http-server-mechanism-factory=global,security-domain=HiThere,mechanism-configurations=[{mechanism-name=BASIC},{mechanism-name=FORM}])
{noformat}
Executing it in admin-only mode, the following exception is thrown on the last command:
{noformat}
[standalone@localhost:9990 /] /subsystem=elytron/http-authentication-factory=HiThere-http:add(http-server-mechanism-factory=global,security-domain=HiThere,mechanism-configurations=[{mechanism-name=BASIC},{mechanism-name=FORM}])
{
"outcome" => "failed",
"failure-description" => undefined,
"rolled-back" => true
}
{noformat}
{noformat}
11:43:43,034 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly Full 19.0.0.Beta2-SNAPSHOT (WildFly Core 11.0.0.Beta8-SNAPSHOT) started in 129ms - Started 81 of 90 services (32 services are lazy, passive or on-demand)
11:43:47,923 INFO [org.jboss.as.controller] (management-handler-thread - 1) WFLYCTL0183: Service status report
WFLYCTL0184: New missing/unsatisfied dependencies:
service org.wildfly.security.security-realm.HiThere (missing) dependents: [service org.wildfly.security.security-domain.HiThere.initial]
WFLYCTL0448: 1 additional services are down due to their dependencies being missing or failed
{noformat}
The execution using the embedded server works fine.
This issue basically is a follow up on WFCORE-4407, where we fixed this issue on the embedded server, however, it looks like we were pretty conservative with the changes. Now we need this on a standard admin-only server mode to allow cloud images to apply the server configuration using CLI operations.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (WFLY-13074) Application context is enabled to mod_cluster for servers that are started as suspended in the JBoss EAP 7.2
by Radoslav Husar (Jira)
[ https://issues.redhat.com/browse/WFLY-13074?page=com.atlassian.jira.plugi... ]
Radoslav Husar updated WFLY-13074:
----------------------------------
Summary: Application context is enabled to mod_cluster for servers that are started as suspended in the JBoss EAP 7.2 (was: application context is enabled to mod_cluster for servers that are started as suspended in the JBoss EAP 7.2)
> Application context is enabled to mod_cluster for servers that are started as suspended in the JBoss EAP 7.2
> ------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-13074
> URL: https://issues.redhat.com/browse/WFLY-13074
> Project: WildFly
> Issue Type: Bug
> Components: mod_cluster, Web (Undertow)
> Affects Versions: 19.0.0.Beta1
> Reporter: Chao Wang
> Assignee: Chao Wang
> Priority: Major
> Labels: downstream_dependency
>
> When a server that is running is suspended, the application contexts are stopped:
> {code:java}
> 2020-01-31 09:27:47,548 DEBUG [org.jboss.modcluster] (ServerService Thread Pool -- 6) MODCLUSTER000008: Received stop context event for default-host:/appname
> 2020-01-31 09:27:47,548 DEBUG [org.jboss.modcluster] (ServerService Thread Pool -- 6) MODCLUSTER000010: Sending DISABLE-APP for default-host:/appname
> 2020-01-31 09:27:47,550 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 6) MODCLUSTER000021: All pending requests drained from default-host:/appname in 0.0 seconds
> {code}
> From undertow loadbalancer:
> {code:java}
> 2020-01-31 09:24:55,828 DEBUG [io.undertow] (default task-1) UT005057: Sending MCMP response to destination: /127.0.0.1:44386, HTTP status: 200, Headers: {Content-Type=[text/plain; charset=ISO-8859-1]}, response: Type=STOP-APP-RSP,JvmRoute=slave:server1Alias=default-host,localhostContext=/appnameRequests=0
> {code}
> But if a server is started as suspended, the contexts are enabled:
> {code:java}
> 2020-01-31 09:34:10,570 DEBUG [org.jboss.modcluster] (ServerService Thread Pool -- 81) MODCLUSTER000005: Received add context event for default-host:/appname
> 2020-01-31 09:34:10,570 DEBUG [org.jboss.modcluster] (ServerService Thread Pool -- 81) MODCLUSTER000007: Received start context event for default-host:/appname
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (DROOLS-5094) KIE-Base and KIE-Session break Test Scenario (Legacy) rhdm 7 (v 7.5.1 on EAP 7.2) Windows 10
by Toni Rikkola (Jira)
[ https://issues.redhat.com/browse/DROOLS-5094?page=com.atlassian.jira.plug... ]
Toni Rikkola updated DROOLS-5094:
---------------------------------
Labels: drools-tools (was: )
> KIE-Base and KIE-Session break Test Scenario (Legacy) rhdm 7 (v 7.5.1 on EAP 7.2) Windows 10
> --------------------------------------------------------------------------------------------
>
> Key: DROOLS-5094
> URL: https://issues.redhat.com/browse/DROOLS-5094
> Project: Drools
> Issue Type: Bug
> Components: Test Scenarios Editor
> Affects Versions: 7.26.0.Final
> Reporter: Charles Herrick
> Assignee: Toni Rikkola
> Priority: Critical
> Labels: drools-tools
> Attachments: image002.png, image004.jpg, image006.jpg, image007.png, image008.jpg
>
>
> bug[1]: Once you set the KIE-Base and a KIE-Session in Settings on a Project, subsequent Test Scenario (Legacy) inherit/adopt the KIE-Base and KIE-Session. The run-scenario fails without even running.
> Workaround:
> 1. Create and build the Test Scenario (Legacy)
> 2. Download the Test Scenario (creates an XML file)
> 3. Edit the XML file to set the Session to :
> <ksessions>
> <string>defaultKieSession</string>
> </ksessions>
> 4. Delete the Test Scenario from Decision-Manager > Space > Project > Assets.
> 5. Import Asset > the edited XML file.
> Now the Test Scenario will run.
> Bug[2]: In the Settings for a specific Test Scenario (Legacy) the KIE-Base and KIE-Session are NOT editable and can not be changed. To fix this you have to follow the workaround.
> Versions: Windows 10, rhdm 7 v 7.5.1, EAP v 7.2, Drools: rhdmAdmin (About) == 7.26 Final
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (DROOLS-1836) Guided Decision Tables should use XLS as the save file format
by Toni Rikkola (Jira)
[ https://issues.redhat.com/browse/DROOLS-1836?page=com.atlassian.jira.plug... ]
Toni Rikkola resolved DROOLS-1836.
----------------------------------
Resolution: Won't Do
> Guided Decision Tables should use XLS as the save file format
> -------------------------------------------------------------
>
> Key: DROOLS-1836
> URL: https://issues.redhat.com/browse/DROOLS-1836
> Project: Drools
> Issue Type: Feature Request
> Components: Guided Decision Table Editor
> Reporter: Toni Rikkola
> Assignee: Toni Rikkola
> Priority: Major
> Labels: drools-tools
>
> We can already export the Guided Decision Tables to XLS, this Jira will first determinate what is needed for importing XLS to the current Guided dtable model.
> h2. Visual differences
> * XLS colored cells, the colors usually have a meaning
> * XLS Font sizes, types, text color and bold/italic/overlined
> * XLS Cell allows the user to set text aligment
> * XLS lets the user to change cell size
> h2. Differences in functional specification
> * The Drools XLS format allows the user to add Guided rules to more than one Excel tab, each tab can have a different kind of table
> * GDST requires each pattern to have a variable name, XLS does not
> * GDST requires each column to have a title, XLS does not
> * GDST stores the value type
> * GDST does not support the XLS forall template
> * GDST has "inner enums" that can be set for columns
> * GDST file contains authoring history
> * XLS does not support generic DRL fracments
> * XLS does not support otherwise
> * XLS does not support Workitems
> * XLS does not support any Guvnor Enums or DSL
> * XLS allows more than one $variable to be used for a single column. For example $param1, $param2 for method($param1,$param2)
> * XLS allows the DRL functions to be declared inside the XLS file
> * XLS can contain XLS formulas
> h2. Some random thoughts
> * If we go full XLS, then we lose the information about the value type that is set into each cell, but then again, maybe this is not that big of a loss since the information can be regained from the DMO.
> * To get the XLS formulas and styles to work we need to write our own GWT Excel
> * GDST file contains authoring history, in XLS form this would be openly editable. Then again, you can text edit the file anyway you want to if you git checkout the GDST XML file
> * A XLS file can also be a rule template or anything else than a dtable. File ending like dtable.xls or gdst.xls would of course fix this.
> * ^ The Guided rule templates might have to move to XLS too. Just to keep things simple, but the XLS templates are made out of two files DRL+XLS
> * There is a need for some kind of migration tool or we keep allow the user to open .gdst and save .xml. This means we need to keep the codes for the old model in our workbench codebase forever and ever.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (DROOLS-2278) Parallel rules compiling does not take into account JVM container security policy
by Mario Fusco (Jira)
[ https://issues.redhat.com/browse/DROOLS-2278?page=com.atlassian.jira.plug... ]
Mario Fusco resolved DROOLS-2278.
---------------------------------
Resolution: Done
Fixed by https://github.com/kiegroup/drools/commit/3331bb5ff2077672deb50115be915ef...
> Parallel rules compiling does not take into account JVM container security policy
> ---------------------------------------------------------------------------------
>
> Key: DROOLS-2278
> URL: https://issues.redhat.com/browse/DROOLS-2278
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 7.5.0.Final
> Environment: Linux 2.6.32-696.13.2.el6.x86_64
> OpenJDK Runtime Environment (build 1.8.0_151-b12)
> OpenJDK 64-Bit Server VM (build 25.151-b12, mixed mode)
> Reporter: Dorin Opris
> Assignee: Mario Fusco
> Priority: Major
>
> We deployed Drools 7.5.0.Final libraries in a java container (commercial product) which specifies a security manager and a policy.
> When running the container with small Drools packages (i.e. number of rules is less than 10) processing goes very well. When it comes to more rules the following exception is issued:
> SEVERE Failed to instantiate <container_unit>; Caused by: org.jini.rio.core.JSBInstantiationException:
> java.security.AccessControlException: access denied ("java.lang.RuntimePermission" "createClassLoader")
> at java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
> at java.security.AccessController.checkPermission(AccessController.java:884)
> at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
> at java.lang.SecurityManager.checkCreateClassLoader(SecurityManager.java:611)
> at java.lang.ClassLoader.checkCreateClassLoader(ClassLoader.java:274)
> at java.lang.ClassLoader.<init>(ClassLoader.java:316)
> at org.drools.core.rule.JavaDialectRuntimeData$PackageClassLoader.<init>(JavaDialectRuntimeData.java:573)
> at org.drools.core.rule.JavaDialectRuntimeData.makeClassLoader(JavaDialectRuntimeData.java:555)
> at org.drools.core.rule.JavaDialectRuntimeData.onAdd(JavaDialectRuntimeData.java:238)
> at org.drools.compiler.rule.builder.dialect.java.JavaDialect.<init>(JavaDialect.java:189)
> at org.drools.compiler.rule.builder.dialect.java.JavaDialectConfiguration.newDialect(JavaDialectConfiguration.java:88)
> at org.drools.compiler.builder.impl.KnowledgeBuilderConfigurationImpl.buildDialectRegistry(KnowledgeBuilderConfigurationImpl.java:377)
> at org.drools.compiler.compiler.PackageRegistry.<init>(PackageRegistry.java:51)
> at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.createPackageRegistry(.java:1051)
> at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.lambda$getOrCreatePackageRegistry$0(KnowledgeBuilderImpl.java:1026)
> at java.util.concurrent.ConcurrentHashMap.computeIfAbsent(ConcurrentHashMap.java:1660)
> at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.getOrCreatePackageRegistry(KnowledgeBuilderImpl.java:1026)
> at org.drools.compiler.builder.impl.TypeDeclarationCache.createTypeDeclarationForBean(TypeDeclarationCache.java:262)
> at org.drools.compiler.builder.impl.TypeDeclarationCache.getAndRegisterTypeDeclaration(TypeDeclarationCache.java:90)
> at org.drools.compiler.builder.impl.TypeDeclarationBuilder.getAndRegisterTypeDeclaration(TypeDeclarationBuilder.java:69)
> at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.getAndRegisterTypeDeclaration(KnowledgeBuilderImpl.java:1781)
> at org.drools.compiler.rule.builder.PatternBuilder.processClassObjectType(PatternBuilder.java:306)
> at org.drools.compiler.rule.builder.PatternBuilder.build(PatternBuilder.java:181)
> at org.drools.compiler.rule.builder.PatternBuilder.build(PatternBuilder.java:151)
> at org.drools.compiler.rule.builder.PatternBuilder.build(PatternBuilder.java:133)
> at org.drools.compiler.rule.builder.GroupElementBuilder.build(GroupElementBuilder.java:66)
> at org.drools.compiler.rule.builder.RuleBuilder.build(RuleBuilder.java:105)
> at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.addRule(KnowledgeBuilderImpl.java:1202)
> at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.lambda$compileRulesLevel$3(KnowledgeBuilderImpl.java:1163)
> at java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:184)
> at java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175)
> at java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1380)
> at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
> at java.util.stream.ForEachOps$ForEachTask.compute(ForEachOps.java:291)
> at java.util.concurrent.CountedCompleter.exec(CountedCompleter.java:731)
> at java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:289)
> at java.util.concurrent.ForkJoinPool$WorkQueue.runTask(ForkJoinPool.java:1056)
> at java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1692)
> at java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:157)
> It seems Drools 7.* version has introduced parallel compilation of rules using Java platform forkJoin threads that, according to its spec, are a bit security restrictive in the sense that container security policy or container class loader access control context is ignored.
> "If a SecurityManager is present and no factory is specified, then the default pool uses a factory supplying threads that have no Permissions enabled. The system class loader is used to load these classes." https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/ForkJoinPo...
> Could Drools fix this serial-parallel asymmetric output of rules compilation logic? Or it's just a Java issue like https://bugs.java.com/view_bug.do?bug_id=8184335 ?
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (JGRP-2421) Don't log an IllegalArgumentException when receiving an invalid delta view
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-2421?page=com.atlassian.jira.plugin... ]
Bela Ban resolved JGRP-2421.
----------------------------
Resolution: Done
> Don't log an IllegalArgumentException when receiving an invalid delta view
> --------------------------------------------------------------------------
>
> Key: JGRP-2421
> URL: https://issues.redhat.com/browse/JGRP-2421
> Project: JGroups
> Issue Type: Enhancement
> Affects Versions: 4.1.6
> Reporter: Dan Berindei
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 5.0, 4.2.1
>
>
> When the cluster is unstable but not because of the network (e.g. excessive load and long GC pauses), a suspected node can keep receiving view updates long after it was excluded from the view.
> The first view triggers a warning about not being a member, but because later delta-views cannot be reconstructed, their warnings look much worse, even though they're about the same thing.
> {noformat}
> 11:31:05,281 WARN [org.jgroups.protocols.pbcast.GMS] (jgroups-79,edg-perf03-47882) edg-perf03-47882: not member of view [edg-perf01-21541|6]; discarding it
> 11:31:16,267 WARN [org.jgroups.protocols.pbcast.GMS] (jgroups-80,edg-perf03-47882) edg-perf03-47882: failed to create view from delta-view; dropping view: java.lang.IllegalStateException: the view-id of the delta view ([edg-perf01-21541|6]) doesn't match the current view-id ([edg-perf01-21541|5]); discarding delta view [edg-perf01-21541|7], ref-view=[edg-perf01-21541|6], left=[edg-perf06-47720]
> {noformat}
> Maybe GMS could keep track of when it receives a view in which it is not a member and stop processing delta views from that node?
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (JGRP-2421) Don't log an IllegalArgumentException when receiving an invalid delta view
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-2421?page=com.atlassian.jira.plugin... ]
Bela Ban commented on JGRP-2421:
--------------------------------
I've come to the conclusion that I don't want to introduce additional state ({{excluded}}) to {{GMS}}, and set it to {{true}} when the member is excluded, and back to {{false}} when a new (merge) view is received.
Instead, I changed the log level from {{WARN}} to {{TRACE}}
> Don't log an IllegalArgumentException when receiving an invalid delta view
> --------------------------------------------------------------------------
>
> Key: JGRP-2421
> URL: https://issues.redhat.com/browse/JGRP-2421
> Project: JGroups
> Issue Type: Enhancement
> Affects Versions: 4.1.6
> Reporter: Dan Berindei
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 5.0, 4.2.1
>
>
> When the cluster is unstable but not because of the network (e.g. excessive load and long GC pauses), a suspected node can keep receiving view updates long after it was excluded from the view.
> The first view triggers a warning about not being a member, but because later delta-views cannot be reconstructed, their warnings look much worse, even though they're about the same thing.
> {noformat}
> 11:31:05,281 WARN [org.jgroups.protocols.pbcast.GMS] (jgroups-79,edg-perf03-47882) edg-perf03-47882: not member of view [edg-perf01-21541|6]; discarding it
> 11:31:16,267 WARN [org.jgroups.protocols.pbcast.GMS] (jgroups-80,edg-perf03-47882) edg-perf03-47882: failed to create view from delta-view; dropping view: java.lang.IllegalStateException: the view-id of the delta view ([edg-perf01-21541|6]) doesn't match the current view-id ([edg-perf01-21541|5]); discarding delta view [edg-perf01-21541|7], ref-view=[edg-perf01-21541|6], left=[edg-perf06-47720]
> {noformat}
> Maybe GMS could keep track of when it receives a view in which it is not a member and stop processing delta views from that node?
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (JGRP-2421) Don't log an IllegalArgumentException when receiving an invalid delta view
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-2421?page=com.atlassian.jira.plugin... ]
Bela Ban commented on JGRP-2421:
--------------------------------
Unit test: {{DeltaViewTest.testViewCannotBeCreatedFromDeltaView()}}:
* View is V0=\{J,K,L,M,N\}
* N is excluded and gets view V1=\{J,K,L,M\}
* N drops V1 as it is not a member
* Delta-view V2=\{J,K,L\} is installed (M left)
* N cannot construct V2, as it refers to V1 which N discarded -> error message
> Don't log an IllegalArgumentException when receiving an invalid delta view
> --------------------------------------------------------------------------
>
> Key: JGRP-2421
> URL: https://issues.redhat.com/browse/JGRP-2421
> Project: JGroups
> Issue Type: Enhancement
> Affects Versions: 4.1.6
> Reporter: Dan Berindei
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 5.0, 4.2.1
>
>
> When the cluster is unstable but not because of the network (e.g. excessive load and long GC pauses), a suspected node can keep receiving view updates long after it was excluded from the view.
> The first view triggers a warning about not being a member, but because later delta-views cannot be reconstructed, their warnings look much worse, even though they're about the same thing.
> {noformat}
> 11:31:05,281 WARN [org.jgroups.protocols.pbcast.GMS] (jgroups-79,edg-perf03-47882) edg-perf03-47882: not member of view [edg-perf01-21541|6]; discarding it
> 11:31:16,267 WARN [org.jgroups.protocols.pbcast.GMS] (jgroups-80,edg-perf03-47882) edg-perf03-47882: failed to create view from delta-view; dropping view: java.lang.IllegalStateException: the view-id of the delta view ([edg-perf01-21541|6]) doesn't match the current view-id ([edg-perf01-21541|5]); discarding delta view [edg-perf01-21541|7], ref-view=[edg-perf01-21541|6], left=[edg-perf06-47720]
> {noformat}
> Maybe GMS could keep track of when it receives a view in which it is not a member and stop processing delta views from that node?
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months