[JBoss JIRA] (DROOLS-1040) Kie server on Tomcat with JACCValve fails authorisation
by Karel Suta (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1040?page=com.atlassian.jira.plugi... ]
Karel Suta commented on DROOLS-1040:
------------------------------------
fixed and merged into master and 6.4.x
> Kie server on Tomcat with JACCValve fails authorisation
> -------------------------------------------------------
>
> Key: DROOLS-1040
> URL: https://issues.jboss.org/browse/DROOLS-1040
> Project: Drools
> Issue Type: Bug
> Components: kie server
> Affects Versions: 6.4.0.Beta1
> Environment: Tomcat
> Kie server 6.4.0-SNAPSHOT
> Reporter: Karel Suta
> Assignee: Karel Suta
> Priority: Minor
> Labels: reported-by-qe
> Fix For: 6.4.0.CR1
>
>
> When Kie server is run on Tomcat container with org.kie.integration.tomcat.JACCValve configured then JBPM operations which needs authorisation invoked on Kie server fails with:
> "User '[UserImpl:'Roles']' does not have permissions to execute operation...".
> Error happens just with JACCValve which is used for Workbench, so this isn't critical issue.
> Issue is caused by JACCValve which register PolicyContextHandler with Subject returning 2 principals in HashSet, one principal represents user, second represent its roles.
> JACCIdentityProvider in Kie server in method getName() returns first principal from Subject which it finds, in case it is roles principal then is returned "Roles" as user name, which is wrong.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years
[JBoss JIRA] (WFCORE-1332) Referrals 'throw' does not work correctly for ldap authentication to mgmt console with MS Active Directory
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1332?page=com.atlassian.jira.plugi... ]
Brian Stansberry moved JBEAP-3048 to WFCORE-1332:
-------------------------------------------------
Project: WildFly Core (was: JBoss Enterprise Application Platform)
Key: WFCORE-1332 (was: JBEAP-3048)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Domain Management
Security
(was: Domain Management)
(was: Security)
Target Release: (was: 7.0.0.GA)
Affects Version/s: 2.0.7.Final
(was: 7.0.0.ER4)
> Referrals 'throw' does not work correctly for ldap authentication to mgmt console with MS Active Directory
> ----------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1332
> URL: https://issues.jboss.org/browse/WFCORE-1332
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management, Security
> Affects Versions: 2.0.7.Final
> Reporter: Ondrej Lukas
> Assignee: Darran Lofthouse
>
> In case when crossRef object to different domain is configured on MS Active Directory for handling referrals and JBoss EAP 7 uses ldap authentication to mgmt console with configured referrals 'throw' then authentication fails for referral users. It is inconsistent with behavior of EAP with another LDAP providers (e.g. Red Hat Directory Server). In correct behavior authentication should pass.
> It seems it is caused by thrown LdapReferralException search method of org.jboss.as.domain.management.security.LdapUserSearcherFactory.LdapUserSearcherImpl before it is handled by try-catch block. Stack trace of thrown LdapReferralException:
> com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2975)
> com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2888)
> com.sun.jndi.ldap.LdapCtx.searchAux(LdapCtx.java:1846)
> com.sun.jndi.ldap.LdapCtx.c_search(LdapCtx.java:1769)
> com.sun.jndi.ldap.LdapCtx.c_search(LdapCtx.java:1786)
> com.sun.jndi.toolkit.ctx.ComponentDirContext.p_search(ComponentDirContext.java:418)
> com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(PartialCompositeDirContext.java:396)
> com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(PartialCompositeDirContext.java:378)
> javax.naming.directory.InitialDirContext.search(InitialDirContext.java:286)
> javax.naming.directory.InitialDirContext.search(InitialDirContext.java:286)
> org.jboss.as.domain.management.security.LdapUserSearcherFactory$LdapUserSearcherImpl.search(LdapUserSearcherFactory.java:125)
> org.jboss.as.domain.management.security.LdapUserSearcherFactory$LdapUserSearcherImpl.search(LdapUserSearcherFactory.java:66)
> org.jboss.as.domain.management.security.LdapCacheService$NoCacheCache.search(LdapCacheService.java:225)
> org.jboss.as.domain.management.security.UserLdapCallbackHandler$LdapCallbackHandler.handle(UserLdapCallbackHandler.java:205)
> org.jboss.as.domain.management.security.SecurityRealmService$1.handle(SecurityRealmService.java:178)
> org.jboss.as.domain.http.server.security.RealmIdentityManager.verify(RealmIdentityManager.java:162)
> org.jboss.as.domain.http.server.security.RealmIdentityManager.verify(RealmIdentityManager.java:141)
> io.undertow.security.impl.BasicAuthenticationMechanism.authenticate(BasicAuthenticationMechanism.java:118)
> org.jboss.as.domain.http.server.security.AuthenticationMechanismWrapper.authenticate(AuthenticationMechanismWrapper.java:52)
> io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:233)
> io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:250)
> io.undertow.security.impl.SecurityContextImpl$AuthAttempter.access$100(SecurityContextImpl.java:219)
> io.undertow.security.impl.SecurityContextImpl.attemptAuthentication(SecurityContextImpl.java:121)
> io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:96)
> io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:89)
> io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:50)
> io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
> io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793)
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> java.lang.Thread.run(Thread.java:745)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years
[JBoss JIRA] (WFLY-6070) Can not deploy a @ConnectionFactoryDefinition if the RA has more <connection-definitions>
by Lin Gao (JIRA)
Lin Gao created WFLY-6070:
-----------------------------
Summary: Can not deploy a @ConnectionFactoryDefinition if the RA has more <connection-definitions>
Key: WFLY-6070
URL: https://issues.jboss.org/browse/WFLY-6070
Project: WildFly
Issue Type: Bug
Components: JCA
Affects Versions: 10.0.0.CR5
Reporter: Lin Gao
Assignee: Lin Gao
Steps to reproduce:
* add a 2nd connection-defintion to testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/jca/deployment/ra.xml:
{noformat}
<connection-definition>
<managedconnectionfactory-class>org.jboss.as.test.integration.jca.rar.MultipleManagedConnectionFactory2</managedconnectionfactory-class>
<connectionfactory-interface>org.jboss.as.test.integration.jca.rar.MultipleConnectionFactory2</connectionfactory-interface>
<connectionfactory-impl-class>org.jboss.as.test.integration.jca.rar.MultipleConnectionFactory2Impl</connectionfactory-impl-class>
<connection-interface>org.jboss.as.test.integration.jca.rar.MultipleConnection2</connection-interface>
<connection-impl-class>org.jboss.as.test.integration.jca.rar.MultipleConnection2Impl</connection-impl-class>
</connection-definition>
{noformat}
* Run the WarServletDeploymentTestCase test
=> it fails because the ConnectionFactoryDefinition objects are no longer deployed.
After debugging, the test fails because the deployed connection definitions are not activated.
The code at org/jboss/as/connector/services/resourceadapters/ResourceAdapterActivatorService.java:232 is preventing the activation and looks suspicious.
It expects that all the MCF in the RA (raMcfClasses) must *all* be in the activation (ijMcfClasses).
With a 2nd <connection-definition> in the RA, it is no longer the case (as the activation only contains a single MCF (MultipleManagedConnectionFactory1).
If I change the code so that it checks that all the MCF in the activations are in the RA, the test passes again.
This issue is preventing me to reuse the code handling the @ConnectionFactoryDefinition to support the @JMSConnectionFactoryDefinition (my JMS RA defines 3 MCF for generic/queue/topic CFs but my activation only defines a single MCF per @JMSConnectionFactoryDefinition).
I've not run it but the same issue is likely for admin objects too (the code in checkActivation is similar)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years
[JBoss JIRA] (DROOLS-1037) Parsing of a complex constraint with an || causes a RuntimeException
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1037?page=com.atlassian.jira.plugi... ]
RH Bugzilla Integration commented on DROOLS-1037:
-------------------------------------------------
Mario Fusco <mfusco(a)redhat.com> changed the Status of [bug 1300692|https://bugzilla.redhat.com/show_bug.cgi?id=1300692] from NEW to MODIFIED
> Parsing of a complex constraint with an || causes a RuntimeException
> --------------------------------------------------------------------
>
> Key: DROOLS-1037
> URL: https://issues.jboss.org/browse/DROOLS-1037
> Project: Drools
> Issue Type: Bug
> Reporter: Mario Fusco
> Assignee: Mario Fusco
> Fix For: 6.4.0.CR1
>
>
> Trying to compile a rule like the following
> {code}
> rule R when
> $p : Person( name == null || (name in (\"Alice\", \"Charlie\", \"David\"))==false )
> then
> list.add($p.getName());
> end
> {code}
> causes the following RuntimeException:
> {code}
> java.lang.RuntimeException
> at org.drools.compiler.rule.builder.PatternBuilder.rewriteCompositeExpressions(PatternBuilder.java:924)
> at org.drools.compiler.rule.builder.PatternBuilder.rewriteCompositeExpressions(PatternBuilder.java:919)
> at org.drools.compiler.rule.builder.PatternBuilder.rewriteOrExpressions(PatternBuilder.java:893)
> at org.drools.compiler.rule.builder.PatternBuilder.buildExpression(PatternBuilder.java:889)
> at org.drools.compiler.rule.builder.PatternBuilder.buildCcdDescr(PatternBuilder.java:860)
> at org.drools.compiler.rule.builder.PatternBuilder.build(PatternBuilder.java:715)
> at org.drools.compiler.rule.builder.PatternBuilder.processConstraintsAndBinds(PatternBuilder.java:580)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years
[JBoss JIRA] (WFLY-6069) Duplicated jipijapa module
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-6069?page=com.atlassian.jira.plugin.... ]
Scott Marlow updated WFLY-6069:
-------------------------------
Description:
modules/system/layers/base/org/hibernate/jipijapa-hibernate4-3/main/jipijapa-hibernate4-3-10.0.0.CR6-redhat-1.jar
modules/system/layers/base/org/hibernate/4.3/jipijapa-hibernate4-3-10.0.0.CR6-redhat-1.jar
was:
modules/system/layers/base/org/hibernate/jipijapa-hibernate4-3/main/jipijapa-hibernate4-3-10.0.0.CR6-redhat-1.jar
modules/system/layers/base/org/hibernate/4.3/jipijapa-hibernate4-3-10.0.0.CR6-redhat-1.jar
Refer to this tattletale report:
http://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/EAP7/view/EAP7-Accep...
> Duplicated jipijapa module
> --------------------------
>
> Key: WFLY-6069
> URL: https://issues.jboss.org/browse/WFLY-6069
> Project: WildFly
> Issue Type: Bug
> Components: Build System
> Affects Versions: 10.0.0.CR5
> Reporter: Jan Martiska
> Assignee: Scott Marlow
> Priority: Critical
> Fix For: 10.0.0.Final
>
>
> modules/system/layers/base/org/hibernate/jipijapa-hibernate4-3/main/jipijapa-hibernate4-3-10.0.0.CR6-redhat-1.jar
> modules/system/layers/base/org/hibernate/4.3/jipijapa-hibernate4-3-10.0.0.CR6-redhat-1.jar
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years
[JBoss JIRA] (JGRP-2007) Adapt code to use new Java 8 features
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2007?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-2007 at 1/26/16 8:50 AM:
---------------------------------------------------------
Also look at
* -MessageBatch-: DONE
* Table (Visitor)
* Use default methods in interfaces
* -Condition / CondVar- : DONE
was (Author: belaban):
Also look at
* -MessageBatch-: DONE
* Table (Visitor)
* Use default methods in interfaces
* Replace NotifyingFuture with CompletableFuture
* -Condition / CondVar- : DONE
> Adapt code to use new Java 8 features
> -------------------------------------
>
> Key: JGRP-2007
> URL: https://issues.jboss.org/browse/JGRP-2007
> Project: JGroups
> Issue Type: Task
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 4.0
>
>
> E.g replace loops for forEach() etc
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years
