[JBoss JIRA] (WFCORE-2459) Missing log that authetication failed in Elytron LdapRealm
by Yeray Borges (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2459?page=com.atlassian.jira.plugi... ]
Yeray Borges reassigned WFCORE-2459:
------------------------------------
Assignee: Yeray Borges (was: Darran Lofthouse)
> Missing log that authetication failed in Elytron LdapRealm
> ----------------------------------------------------------
>
> Key: WFCORE-2459
> URL: https://issues.jboss.org/browse/WFCORE-2459
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Reporter: Ondrej Lukas
> Assignee: Yeray Borges
>
> In case when wrong password is passed during authentication through LdapRealm then server log does not include information that 'authentication failed'.
> Following log occurs in server.log:
> {code}
> 2017-02-20 13:16:41,482 DEBUG [org.wildfly.security] (default task-2) Trying to create identity for principal [jduke].
> 2017-02-20 13:16:41,483 DEBUG [org.wildfly.security] (default task-2) Executing search [(uid={0})] in context [ou=People,dc=jboss,dc=org] with arguments [[Ljava.lang.String;@3e8a4972]. Returning attributes are [[userPassword]]. Binary attributes are [[]].
> 2017-02-20 13:16:41,491 DEBUG [org.wildfly.security] (default task-2) Found entry [uid=jduke,ou=People,dc=jboss,dc=org].
> 2017-02-20 13:16:41,493 DEBUG [org.wildfly.security] (default task-2) Identity for principal [jduke] found at [uid=jduke,ou=People,dc=jboss,dc=org].
> 2017-02-20 13:16:41,504 DEBUG [org.wildfly.security] (default task-2) Context [javax.naming.ldap.InitialLdapContext@3db0aa06] was closed. Connection closed or just returned to the pool.
> 2017-02-20 13:16:41,506 DEBUG [org.wildfly.security] (default task-2) User jduke authorization failed.
> 2017-02-20 13:16:41,506 TRACE [org.wildfly.security] (default task-2) Handling AuthenticationCompleteCallback: fail
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (WFLY-8893) Improve Elytron audit log test cases
by Ondrej Lukas (JIRA)
Ondrej Lukas created WFLY-8893:
----------------------------------
Summary: Improve Elytron audit log test cases
Key: WFLY-8893
URL: https://issues.jboss.org/browse/WFLY-8893
Project: WildFly
Issue Type: Bug
Components: Test Suite
Reporter: Ondrej Lukas
Add tests for:
* test whether access with wrong password is logged
* test whether access with empty password is logged
Remove test {{testAuthWithEmptyName}} since it is unsupported case - see JBEAP-10997.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (WFLY-8891) Cluster deployment is not happening with wildfly 10
by Subash singh (JIRA)
[ https://issues.jboss.org/browse/WFLY-8891?page=com.atlassian.jira.plugin.... ]
Subash singh commented on WFLY-8891:
------------------------------------
Hi Radoslav,
Thanks for quick response on this.
I have checked on my vm multicast is enabled for eth0 and eth1 but not for lo.
when i check it by executing below cmd found that cluster id is using lo interface.
{color:#f6c342}# netstat -g
IPv6/IPv4 Group Memberships
Interface RefCnt Group
--------------- ------ ---------------------
lo 1 225.9.9.25
lo 1 all-systems.mcast.net
eth0 1 ntds1r.mcast.net
eth0 1 all-systems.mcast.net
eth1 1 all-systems.mcast.net
lo 1 ff02::1
eth0 1 ff02::202
eth0 1 ff02::1:ffb9:a7dd
eth0 1 ff02::1
eth1 1 ff02::202
{color}
my cluster setup is not working because it is using *lo * interface and for *lo* multicast is not enable?
can you suggest how to proceed further.
Thanks
Subash Singh
> Cluster deployment is not happening with wildfly 10
> ---------------------------------------------------
>
> Key: WFLY-8891
> URL: https://issues.jboss.org/browse/WFLY-8891
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.0.0.Final
> Environment: OS - rhel- 6.7
> JRE - openjdk 1.8
> Keycloak-3.0.0
> Reporter: Subash singh
> Assignee: Paul Ferraro
> Priority: Critical
> Original Estimate: 2 days
> Remaining Estimate: 2 days
>
> When we reviewed the logs of the second instance, we saw:
> 2017-06-05 14:33:05,123 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-3) ISPN000078: Starting JGroups channel web
> 2017-06-05 14:33:05,123 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-5) ISPN000078: Starting JGroups channel keycloak
> 2017-06-05 14:33:05,123 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-1) ISPN000078: Starting JGroups channel server
> 2017-06-05 14:33:05,123 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-2) ISPN000078: Starting JGroups channel ejb
> 2017-06-05 14:33:05,123 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-7) ISPN000078: Starting JGroups channel hibernate
> Received new cluster view for channel keycloak:* [keycloak02|0] (1) [keycloak02]*
> 2017-06-05 14:33:05,148 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-7) ISPN000094: Received new cluster view for channel hibernate: [keycloak02|0] (1) [keycloak02]
> 2017-06-05 14:33:05,149 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-2) ISPN000094: Received new cluster view for channel ejb: [keycloak02|0] (1) [keycloak02]
> 2017-06-05 14:33:05,149 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-1) ISPN000094: Received new cluster view for channel server: [keycloak02|0] (1) [keycloak02]
> 2017-06-05 14:33:05,149 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-3) ISPN000094: Received new cluster view for channel web: [keycloak02|0] (1) [keycloak02]
> both nodes are not joining the cluster.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (WFLY-8892) Create test case for Elytron Security Domain
by Ondrej Lukas (JIRA)
Ondrej Lukas created WFLY-8892:
----------------------------------
Summary: Create test case for Elytron Security Domain
Key: WFLY-8892
URL: https://issues.jboss.org/browse/WFLY-8892
Project: WildFly
Issue Type: Bug
Components: Test Suite
Reporter: Ondrej Lukas
Create test case for Elytron Security Domain. Testing of most of functionality and attributes of Elytron security-domain subsystem resource is already covered by another test cases in {{org.wildfly.test.integration.elytron.*}} package. This test case should cover only scenarios which are not covered by different test cases.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (DROOLS-1593) Ruleflow Split (XOR) can't find valid outgoing connection
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1593?page=com.atlassian.jira.plugi... ]
Mario Fusco commented on DROOLS-1593:
-------------------------------------
I sent a pull request that should fix this problem https://github.com/kiegroup/drools/pull/1301 and another one that reproduces it inside jbpm https://github.com/kiegroup/jbpm/pull/867
[~McCloud], note however that also your original test case is green if you create the ksession with the ForceEagerActivationOption like in:
{code}
KieSessionConfiguration sessionConf = kieServices.newKieSessionConfiguration();
sessionConf.setOption( ForceEagerActivationOption.YES );
StatelessKieSession kieSession = kieContainer.newStatelessKieSession("stateless-kie-session", sessionConf);
{code}
I believe that internally jbpm always uses that option. [~swiderski.maciej], can you confirm?
> Ruleflow Split (XOR) can't find valid outgoing connection
> ---------------------------------------------------------
>
> Key: DROOLS-1593
> URL: https://issues.jboss.org/browse/DROOLS-1593
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.5.0.Final, 7.0.0.CR3
> Environment: Drools 7.0.0-SNAPSHOT, Oracle Hotspot 1.8.0_112, KIE-Server, OpenShift DecisionServer
> Reporter: Duncan Doyle
> Assignee: Mario Fusco
>
> This seems like a regression, as this used to work in 6.4.0.Final, but broke somewhere before 6.5.0.Final. Still broken in 7.0.0-SNAPSHOT. (I actually found it in the OpenShift DecisionServer/KIE-Server image).
> See this reproducer: https://github.com/DuncanDoyle/ruleflow-split-problem
> I have a ruleflow-group that has a split-node (XOR Gateway) directly after the start-node. The outgoing sequence flows of that XOR have a Drools LHS that checks whether a fact is present in working memory (in this reproducer it's a String)
> - exists java.lang.String()
> - not java.lang.String()
> Only if that fact exists do I want to continue my ruleflow, if the fact is not there, I stop.
> I use a StatelessKieSession in which I;
> - insert a String
> - start the process
> - fire the rules
> This used to work fine in 6.4.0.Final and below, but since 6.5.0.Final I get an exception:
> {code}
> org.jbpm.workflow.instance.WorkflowRuntimeException: [test-process:1 - Has Strings?:4] -- XOR split could not find at least one valid outgoing connection for split Has Strings?
> at org.jbpm.workflow.instance.node.SplitInstance.internalTrigger(SplitInstance.java:66)
> at org.jbpm.workflow.instance.impl.NodeInstanceImpl.trigger(NodeInstanceImpl.java:174)
> at org.jbpm.workflow.instance.impl.NodeInstanceImpl.triggerNodeInstance(NodeInstanceImpl.java:367)
> at org.jbpm.workflow.instance.impl.NodeInstanceImpl.triggerCompleted(NodeInstanceImpl.java:326)
> at org.jbpm.workflow.instance.node.StartNodeInstance.triggerCompleted(StartNodeInstance.java:72)
> at org.jbpm.workflow.instance.node.StartNodeInstance.internalTrigger(StartNodeInstance.java:43)
> at org.jbpm.workflow.instance.impl.NodeInstanceImpl.trigger(NodeInstanceImpl.java:174)
> at org.jbpm.ruleflow.instance.RuleFlowProcessInstance.internalStart(RuleFlowProcessInstance.java:38)
> at org.jbpm.process.instance.impl.ProcessInstanceImpl.start(ProcessInstanceImpl.java:235)
> at org.jbpm.workflow.instance.impl.WorkflowProcessInstanceImpl.start(WorkflowProcessInstanceImpl.java:443)
> at org.jbpm.process.instance.ProcessRuntimeImpl.startProcessInstance(ProcessRuntimeImpl.java:208)
> at org.jbpm.process.instance.ProcessRuntimeImpl.startProcess(ProcessRuntimeImpl.java:192)
> at org.jbpm.process.instance.ProcessRuntimeImpl.startProcess(ProcessRuntimeImpl.java:184)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.startProcess(StatefulKnowledgeSessionImpl.java:1859)
> at org.drools.core.command.runtime.process.StartProcessCommand.execute(StartProcessCommand.java:121)
> at org.drools.core.command.runtime.process.StartProcessCommand.execute(StartProcessCommand.java:39)
> at org.drools.core.command.runtime.BatchExecutionCommandImpl.execute(BatchExecutionCommandImpl.java:156)
> at org.drools.core.command.runtime.BatchExecutionCommandImpl.execute(BatchExecutionCommandImpl.java:64)
> at org.drools.core.impl.StatelessKnowledgeSessionImpl.execute(StatelessKnowledgeSessionImpl.java:238)
> at org.jboss.ddoyle.ruleflow.test.RuleflowTest.testRuleflowWithSingleFire(RuleflowTest.java:28)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86)
> at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:678)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)
> Caused by: java.lang.IllegalArgumentException: XOR split could not find at least one valid outgoing connection for split Has Strings?
> at org.jbpm.workflow.instance.node.SplitInstance.executeStrategy(SplitInstance.java:110)
> at org.jbpm.workflow.instance.node.SplitInstance.internalTrigger(SplitInstance.java:62)
> ... 42 more
> {code}
> What seems to be causing this is that the rules in the sequence flows are not yet fired when the process arrives at the XOR node, causing it to not be able to find an outgoing connection.
> What does work is if I add an extra "fireAllRules" command BEFORE the "startProcess" command. In that case the flow behaves as it used to. So I need 2 "fireAllRules" commands. What does NOT work is when I only add a "fireAllRules" command before the startProcess command. In that case the rules in the RFG nodes are not fired (but the XOR does not throw an exception in that case).
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (WFLY-8891) Cluster deployment is not happening with wildfly 10
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-8891?page=com.atlassian.jira.plugin.... ]
Radoslav Husar commented on WFLY-8891:
--------------------------------------
This is a topic for the forums community.jboss.org not issue tracker.
How did you configure discovery (jgroups subsystem configuration)? By default the discovery mechanism uses udp multicast, make sure your network supports multicast.
> Cluster deployment is not happening with wildfly 10
> ---------------------------------------------------
>
> Key: WFLY-8891
> URL: https://issues.jboss.org/browse/WFLY-8891
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.0.0.Final
> Environment: OS - rhel- 6.7
> JRE - openjdk 1.8
> Keycloak-3.0.0
> Reporter: Subash singh
> Assignee: Paul Ferraro
> Priority: Critical
> Original Estimate: 2 days
> Remaining Estimate: 2 days
>
> When we reviewed the logs of the second instance, we saw:
> 2017-06-05 14:33:05,123 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-3) ISPN000078: Starting JGroups channel web
> 2017-06-05 14:33:05,123 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-5) ISPN000078: Starting JGroups channel keycloak
> 2017-06-05 14:33:05,123 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-1) ISPN000078: Starting JGroups channel server
> 2017-06-05 14:33:05,123 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-2) ISPN000078: Starting JGroups channel ejb
> 2017-06-05 14:33:05,123 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-7) ISPN000078: Starting JGroups channel hibernate
> Received new cluster view for channel keycloak:* [keycloak02|0] (1) [keycloak02]*
> 2017-06-05 14:33:05,148 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-7) ISPN000094: Received new cluster view for channel hibernate: [keycloak02|0] (1) [keycloak02]
> 2017-06-05 14:33:05,149 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-2) ISPN000094: Received new cluster view for channel ejb: [keycloak02|0] (1) [keycloak02]
> 2017-06-05 14:33:05,149 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-1) ISPN000094: Received new cluster view for channel server: [keycloak02|0] (1) [keycloak02]
> 2017-06-05 14:33:05,149 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-3) ISPN000094: Received new cluster view for channel web: [keycloak02|0] (1) [keycloak02]
> both nodes are not joining the cluster.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month