May 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (ELY-970) Elytron Ldap Realm searches roles before validating password when direct verification and referral mode follow are used

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-970?page=com.atlassian.jira.plugin.sy... ] Jan Kalina closed ELY-970. -------------------------- Fix Version/s: 1.1.0.Beta48 Resolution: Cannot Reproduce Bug Unable to reproduce nor by original reporter - closing. > Elytron Ldap Realm searches roles before validating password when direct verification and referral mode follow are used > ----------------------------------------------------------------------------------------------------------------------- > > Key: ELY-970 > URL: https://issues.jboss.org/browse/ELY-970 > Project: WildFly Elytron > Issue Type: Bug > Components: Realms > Affects Versions: 1.1.0.Beta25 > Reporter: Ondrej Lukas > Assignee: Jan Kalina > Priority: Critical > Fix For: 1.1.0.Beta48 > > > In case when Ldap Realm is set to use direct verification and referenced DirContext uses referral mode follow, then roles for referral user are searched before actual user password is validated. In this case following flow is used: > # searching for username > # searching for roles (i.e. searching for attributes) > # validating password for username > It means even if wrong password is used then roles in LDAP are searched. Password should be validated before some roles are searched. Current behavior can result to performance issues. > This is the same issue as ELY-760 but only for case when direct verification and referral mode follow are used and user from referral tries to authenticate. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ELY-970) Elytron Ldap Realm searches roles before validating password when direct verification and referral mode follow are used

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-970?page=com.atlassian.jira.plugin.sy... ] Jan Kalina reassigned ELY-970: ------------------------------ Assignee: Jan Kalina (was: Darran Lofthouse) > Elytron Ldap Realm searches roles before validating password when direct verification and referral mode follow are used > ----------------------------------------------------------------------------------------------------------------------- > > Key: ELY-970 > URL: https://issues.jboss.org/browse/ELY-970 > Project: WildFly Elytron > Issue Type: Bug > Components: Realms > Affects Versions: 1.1.0.Beta25 > Reporter: Ondrej Lukas > Assignee: Jan Kalina > Priority: Critical > > In case when Ldap Realm is set to use direct verification and referenced DirContext uses referral mode follow, then roles for referral user are searched before actual user password is validated. In this case following flow is used: > # searching for username > # searching for roles (i.e. searching for attributes) > # validating password for username > It means even if wrong password is used then roles in LDAP are searched. Password should be validated before some roles are searched. Current behavior can result to performance issues. > This is the same issue as ELY-760 but only for case when direct verification and referral mode follow are used and user from referral tries to authenticate. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1590) The behavior of rule flow is different in drools 6.4.0 Final and 6.5.0 Final

by GaoShengwei GaoShengwei (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1590?page=com.atlassian.jira.plugi... ] GaoShengwei GaoShengwei updated DROOLS-1590: -------------------------------------------- Description: I am using drools 6.5.0 Final. When I run sample code of section "starting a ruleflow from a rule" in documentation (https://nheron.gitbooks.io/droolsonboarding/content/gettingStarted/lesson...), the output sequence is different from the screenshot. But when I switched to drools version to 6.4.0 Final, the output was extactly same with screenshot. was: I am using drools 6.5.0 Final. When I run sample code of section "starting a ruleflow from a rule" in documentation (https://nheron.gitbooks.io/droolsonboarding/content/gettingStarted/lesson...), the output is different from the screenshot. But when I switched to drools version to 6.4.0 Final, the output was extactly same with screenshot. > The behavior of rule flow is different in drools 6.4.0 Final and 6.5.0 Final > ---------------------------------------------------------------------------- > > Key: DROOLS-1590 > URL: https://issues.jboss.org/browse/DROOLS-1590 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 6.5.0.Final > Reporter: GaoShengwei GaoShengwei > Assignee: Mario Fusco > Attachments: BaiduHi_2017-5-31_18-1-18.png, BaiduHi_2017-5-31_18-2-54.png > > > I am using drools 6.5.0 Final. When I run sample code of section "starting a ruleflow from a rule" in documentation (https://nheron.gitbooks.io/droolsonboarding/content/gettingStarted/lesson...), the output sequence is different from the screenshot. > But when I switched to drools version to 6.4.0 Final, the output was extactly same with screenshot. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1590) The behavior of rule flow is different in drools 6.4.0 Final and 6.5.0 Final

by GaoShengwei GaoShengwei (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1590?page=com.atlassian.jira.plugi... ] GaoShengwei GaoShengwei updated DROOLS-1590: -------------------------------------------- Description: I am using drools 6.5.0 Final. When I run sample code of section "starting a ruleflow from a rule" in documentation (https://nheron.gitbooks.io/droolsonboarding/content/gettingStarted/lesson...), the output sequence is different from the screenshot. But when I switched to drools version to 6.4.0 Final, the output sequence was extactly same with screenshot. was: I am using drools 6.5.0 Final. When I run sample code of section "starting a ruleflow from a rule" in documentation (https://nheron.gitbooks.io/droolsonboarding/content/gettingStarted/lesson...), the output sequence is different from the screenshot. But when I switched to drools version to 6.4.0 Final, the output was extactly same with screenshot. > The behavior of rule flow is different in drools 6.4.0 Final and 6.5.0 Final > ---------------------------------------------------------------------------- > > Key: DROOLS-1590 > URL: https://issues.jboss.org/browse/DROOLS-1590 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 6.5.0.Final > Reporter: GaoShengwei GaoShengwei > Assignee: Mario Fusco > Attachments: BaiduHi_2017-5-31_18-1-18.png, BaiduHi_2017-5-31_18-2-54.png > > > I am using drools 6.5.0 Final. When I run sample code of section "starting a ruleflow from a rule" in documentation (https://nheron.gitbooks.io/droolsonboarding/content/gettingStarted/lesson...), the output sequence is different from the screenshot. > But when I switched to drools version to 6.4.0 Final, the output sequence was extactly same with screenshot. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1590) The behavior of rule flow is different in drools 6.4.0 Final and 6.5.0 Final

by GaoShengwei GaoShengwei (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1590?page=com.atlassian.jira.plugi... ] GaoShengwei GaoShengwei updated DROOLS-1590: -------------------------------------------- Description: I am using drools 6.5.0 Final. When I run sample code of section "starting a ruleflow from a rule" in documentation (https://nheron.gitbooks.io/droolsonboarding/content/gettingStarted/lesson...), the output is different from the screenshot. But when I switched to drools version to 6.4.0 Final, the output was extactly same with screenshot. > The behavior of rule flow is different in drools 6.4.0 Final and 6.5.0 Final > ---------------------------------------------------------------------------- > > Key: DROOLS-1590 > URL: https://issues.jboss.org/browse/DROOLS-1590 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 6.5.0.Final > Reporter: GaoShengwei GaoShengwei > Assignee: Mario Fusco > Attachments: BaiduHi_2017-5-31_18-1-18.png, BaiduHi_2017-5-31_18-2-54.png > > > I am using drools 6.5.0 Final. When I run sample code of section "starting a ruleflow from a rule" in documentation (https://nheron.gitbooks.io/droolsonboarding/content/gettingStarted/lesson...), the output is different from the screenshot. > But when I switched to drools version to 6.4.0 Final, the output was extactly same with screenshot. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1590) The behavior of rule flow is different in drools 6.4.0 Final and 6.5.0 Final

by GaoShengwei GaoShengwei (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1590?page=com.atlassian.jira.plugi... ] GaoShengwei GaoShengwei updated DROOLS-1590: -------------------------------------------- Attachment: BaiduHi_2017-5-31_18-1-18.png BaiduHi_2017-5-31_18-2-54.png > The behavior of rule flow is different in drools 6.4.0 Final and 6.5.0 Final > ---------------------------------------------------------------------------- > > Key: DROOLS-1590 > URL: https://issues.jboss.org/browse/DROOLS-1590 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 6.5.0.Final > Reporter: GaoShengwei GaoShengwei > Assignee: Mario Fusco > Attachments: BaiduHi_2017-5-31_18-1-18.png, BaiduHi_2017-5-31_18-2-54.png > > > I am using drools 6.5.0 Final. When I run sample code of section "starting a ruleflow from a rule" in documentation (https://nheron.gitbooks.io/droolsonboarding/content/gettingStarted/lesson...), the output is different from the screenshot. > But when I switched to drools version to 6.4.0 Final, the output was extactly same with screenshot. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1590) The behavior of rule flow is different in drools 6.4.0 Final and 6.5.0 Final

by GaoShengwei GaoShengwei (JIRA)

GaoShengwei GaoShengwei created DROOLS-1590: ----------------------------------------------- Summary: The behavior of rule flow is different in drools 6.4.0 Final and 6.5.0 Final Key: DROOLS-1590 URL: https://issues.jboss.org/browse/DROOLS-1590 Project: Drools Issue Type: Bug Components: core engine Affects Versions: 6.5.0.Final Reporter: GaoShengwei GaoShengwei Assignee: Mario Fusco -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ELY-1151) Empty authorization name for Digest mechanism causes authentication fail

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-1151?page=com.atlassian.jira.plugin.s... ] Jan Kalina updated ELY-1151: ---------------------------- Fix Version/s: (was: 1.1.0.Beta44) > Empty authorization name for Digest mechanism causes authentication fail > ------------------------------------------------------------------------ > > Key: ELY-1151 > URL: https://issues.jboss.org/browse/ELY-1151 > Project: WildFly Elytron > Issue Type: Bug > Affects Versions: 1.1.0.Beta38 > Reporter: Ondrej Lukas > Assignee: Jan Kalina > Priority: Blocker > > SASL specification says about Authorization Identity String [1]: > {quote} > If the authorization identity string is absent, the client is requesting to act as the identity the server associates with the client's credentials. *An empty string is equivalent to an absent authorization identity.* > {quote} > In case when authentication configuration includes empty name for authorization name then authentication fail. In correct behavior authentication name should be used if authorization name is empty string. > It is caused by passing empty {{defaultName}} to {{NameCallback}} constructor which results to {{IllegalArgumentException}}. Condition in [2] checks only non-null value of {{authorizationId}} but it seems it should also check empty name. > It can be reproduced with correctly set wildfly-config.xml (i.e. configuration where authentication succeed) - in case {{set-authorization-name}} element with empty string is added to this configuration file then authentication starts to fail. > The same issue can occurs for every supported SASL mechanism. In needs to be revisited. > We request blocker flag since current behavior violates SASL specification. > [1] https://tools.ietf.org/html/rfc4422#section-3.4.1 > [2] https://github.com/wildfly-security/wildfly-elytron/blob/596f25e853c8fbae... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ELY-1151) Empty authorization name for Digest mechanism causes authentication fail

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-1151?page=com.atlassian.jira.plugin.s... ] Jan Kalina commented on ELY-1151: --------------------------------- PR 810: client side NameCallback PR 848: server side AuthorizationCallback > Empty authorization name for Digest mechanism causes authentication fail > ------------------------------------------------------------------------ > > Key: ELY-1151 > URL: https://issues.jboss.org/browse/ELY-1151 > Project: WildFly Elytron > Issue Type: Bug > Affects Versions: 1.1.0.Beta38 > Reporter: Ondrej Lukas > Assignee: Jan Kalina > Priority: Blocker > Fix For: 1.1.0.Beta44 > > > SASL specification says about Authorization Identity String [1]: > {quote} > If the authorization identity string is absent, the client is requesting to act as the identity the server associates with the client's credentials. *An empty string is equivalent to an absent authorization identity.* > {quote} > In case when authentication configuration includes empty name for authorization name then authentication fail. In correct behavior authentication name should be used if authorization name is empty string. > It is caused by passing empty {{defaultName}} to {{NameCallback}} constructor which results to {{IllegalArgumentException}}. Condition in [2] checks only non-null value of {{authorizationId}} but it seems it should also check empty name. > It can be reproduced with correctly set wildfly-config.xml (i.e. configuration where authentication succeed) - in case {{set-authorization-name}} element with empty string is added to this configuration file then authentication starts to fail. > The same issue can occurs for every supported SASL mechanism. In needs to be revisited. > We request blocker flag since current behavior violates SASL specification. > [1] https://tools.ietf.org/html/rfc4422#section-3.4.1 > [2] https://github.com/wildfly-security/wildfly-elytron/blob/596f25e853c8fbae... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-502) ClasspathKieProject fails vfs: try to unzip exploded jar

by Nicolas-Xavier Vanderlinden (JIRA)

[ https://issues.jboss.org/browse/DROOLS-502?page=com.atlassian.jira.plugin... ] Nicolas-Xavier Vanderlinden commented on DROOLS-502: ---------------------------------------------------- Bug fixed in the 7.0.0 version (DROOLS-1065). You can close this ticket. > ClasspathKieProject fails vfs: try to unzip exploded jar > -------------------------------------------------------- > > Key: DROOLS-502 > URL: https://issues.jboss.org/browse/DROOLS-502 > Project: Drools > Issue Type: Bug > Affects Versions: 6.1.0.Beta4, 6.2.0.CR3 > Reporter: Nicolas-Xavier Vanderlinden > Assignee: Mark Proctor > > Drools is not able to load kmodule.xml from an exploded jar inside an exploded ear. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 6 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira May 2017