March 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-8286) Elytron, log cause of LoginException during obraining ticket

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/WFLY-8286?page=com.atlassian.jira.plugin.... ] David Lloyd commented on WFLY-8286: ----------------------------------- In commit 8653945673c5712ce533db1cd21db8ee6a2b6e59 we switched from multiple server credentials to a single credential. This, and also using SecurityFactory for this, might be an error: we should probably convert this to CredentialSource so it works the same way that client auth does. [~dlofthouse] WDYT? I also think that absorbing the GSE is probably wrong in this case. It should be propagated to cause an auth failure. > Elytron, log cause of LoginException during obraining ticket > ------------------------------------------------------------ > > Key: WFLY-8286 > URL: https://issues.jboss.org/browse/WFLY-8286 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Martin Choma > Assignee: Darran Lofthouse > Priority: Critical > > I get to situation where in method {{GSSCredentialSecurityFactory.createGSSCredential()}} the cause of LoginException is hide from user. > In log there is > {code:title=server.log} > 14:26:07,751 TRACE [org.wildfly.security] (default task-1) java.security.GeneralSecurityException: ELY01121: Unable to perform initial JAAS login. > {code} > But with debugger I get to obvious cause {{javax.security.auth.login.LoginException: Bad JAAS configuration: credsType and keytab values are not compatible}}, but this is not logged into log. > Setting to high priority, because logging useful information is esential for troubleshooting fragile Kerberos setup. > Mesage > {code:java|title=ElytronMessages} > @Message(id = 1121, value = "Unable to perform initial JAAS login.") > GeneralSecurityException unableToPerformInitialLogin(@Cause LoginException cause); > {code} > is created in > {code:java|title=GSSCredentialSecurityFactory.java#L283} > } catch (LoginException e) { > throw log.unableToPerformInitialLogin(e); > } > {code} > and logged into log by > {code:java|title=ServerAuthenticationContext.java#L847} > } catch (GeneralSecurityException e) { > // skip this credential > log.trace(e); > } > {code} > An more importantly. Question here is if some global issue should follow up? Because problem is in usage of log.trace(e) where although cause exception is avalaible, effectivelly is called log.trace(e.toString()) and cause is hidden; So probably some global check should be performed in elytron codebase if other such occurences aren't also problematic. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8286) Elytron, log cause of LoginException during obraining ticket

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/WFLY-8286?page=com.atlassian.jira.plugin.... ] David Lloyd commented on WFLY-8286: ----------------------------------- In this case though the code does not look right. > Elytron, log cause of LoginException during obraining ticket > ------------------------------------------------------------ > > Key: WFLY-8286 > URL: https://issues.jboss.org/browse/WFLY-8286 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Martin Choma > Assignee: Darran Lofthouse > Priority: Critical > > I get to situation where in method {{GSSCredentialSecurityFactory.createGSSCredential()}} the cause of LoginException is hide from user. > In log there is > {code:title=server.log} > 14:26:07,751 TRACE [org.wildfly.security] (default task-1) java.security.GeneralSecurityException: ELY01121: Unable to perform initial JAAS login. > {code} > But with debugger I get to obvious cause {{javax.security.auth.login.LoginException: Bad JAAS configuration: credsType and keytab values are not compatible}}, but this is not logged into log. > Setting to high priority, because logging useful information is esential for troubleshooting fragile Kerberos setup. > Mesage > {code:java|title=ElytronMessages} > @Message(id = 1121, value = "Unable to perform initial JAAS login.") > GeneralSecurityException unableToPerformInitialLogin(@Cause LoginException cause); > {code} > is created in > {code:java|title=GSSCredentialSecurityFactory.java#L283} > } catch (LoginException e) { > throw log.unableToPerformInitialLogin(e); > } > {code} > and logged into log by > {code:java|title=ServerAuthenticationContext.java#L847} > } catch (GeneralSecurityException e) { > // skip this credential > log.trace(e); > } > {code} > An more importantly. Question here is if some global issue should follow up? Because problem is in usage of log.trace(e) where although cause exception is avalaible, effectivelly is called log.trace(e.toString()) and cause is hidden; So probably some global check should be performed in elytron codebase if other such occurences aren't also problematic. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8286) Elytron, log cause of LoginException during obraining ticket

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/WFLY-8286?page=com.atlassian.jira.plugin.... ] David Lloyd commented on WFLY-8286: ----------------------------------- I think the solution to this should be that we accumulate encountered Throwables; then if we throw an exception in the end, we can attach them as suppressed. > Elytron, log cause of LoginException during obraining ticket > ------------------------------------------------------------ > > Key: WFLY-8286 > URL: https://issues.jboss.org/browse/WFLY-8286 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Martin Choma > Assignee: Darran Lofthouse > Priority: Critical > > I get to situation where in method {{GSSCredentialSecurityFactory.createGSSCredential()}} the cause of LoginException is hide from user. > In log there is > {code:title=server.log} > 14:26:07,751 TRACE [org.wildfly.security] (default task-1) java.security.GeneralSecurityException: ELY01121: Unable to perform initial JAAS login. > {code} > But with debugger I get to obvious cause {{javax.security.auth.login.LoginException: Bad JAAS configuration: credsType and keytab values are not compatible}}, but this is not logged into log. > Setting to high priority, because logging useful information is esential for troubleshooting fragile Kerberos setup. > Mesage > {code:java|title=ElytronMessages} > @Message(id = 1121, value = "Unable to perform initial JAAS login.") > GeneralSecurityException unableToPerformInitialLogin(@Cause LoginException cause); > {code} > is created in > {code:java|title=GSSCredentialSecurityFactory.java#L283} > } catch (LoginException e) { > throw log.unableToPerformInitialLogin(e); > } > {code} > and logged into log by > {code:java|title=ServerAuthenticationContext.java#L847} > } catch (GeneralSecurityException e) { > // skip this credential > log.trace(e); > } > {code} > An more importantly. Question here is if some global issue should follow up? Because problem is in usage of log.trace(e) where although cause exception is avalaible, effectivelly is called log.trace(e.toString()) and cause is hidden; So probably some global check should be performed in elytron codebase if other such occurences aren't also problematic. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8202) CS tool, format Missing required option

by Martin Choma (JIRA)

[ https://issues.jboss.org/browse/WFLY-8202?page=com.atlassian.jira.plugin.... ] Martin Choma commented on WFLY-8202: ------------------------------------ If it is not possible to tweak library behavior, then keep as is. > CS tool, format Missing required option > --------------------------------------- > > Key: WFLY-8202 > URL: https://issues.jboss.org/browse/WFLY-8202 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Martin Choma > Assignee: Ilia Vassilev > Labels: credential-store, user_experience, wildfly-elytron-tool > > There is validation on required option. > {code} > [mchoma@localhost bin]$ java -jar wildfly-elytron-tool.jar credential-store > Missing required option: [-a Add new alias to the credential store, -r Remove alias from the credential store, -e Check if alias exists within the credential store, -v Display all aliases, -h Get help with usage of this command][mchoma@localhost bin]$ > {code} > However it is one line message. I would prefer mulitline message for readability as > {code} > [mchoma@localhost bin]$ java -jar wildfly-elytron-tool.jar credential-store > Missing one of required options: > -a Add new alias to the credential store, > -r Remove alias from the credential store, > -e Check if alias exists within the credential store, > -v Display all aliases, > -h Get help with usage of this command > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8286) Elytron, log cause of LoginException during obraining ticket

by Martin Choma (JIRA)

Martin Choma created WFLY-8286: ---------------------------------- Summary: Elytron, log cause of LoginException during obraining ticket Key: WFLY-8286 URL: https://issues.jboss.org/browse/WFLY-8286 Project: WildFly Issue Type: Bug Components: Security Reporter: Martin Choma Assignee: Darran Lofthouse Priority: Critical I get to situation where in method {{GSSCredentialSecurityFactory.createGSSCredential()}} the cause of LoginException is hide from user. In log there is {code:title=server.log} 14:26:07,751 TRACE [org.wildfly.security] (default task-1) java.security.GeneralSecurityException: ELY01121: Unable to perform initial JAAS login. {code} But with debugger I get to obvious cause {{javax.security.auth.login.LoginException: Bad JAAS configuration: credsType and keytab values are not compatible}}, but this is not logged into log. Setting to high priority, because logging useful information is esential for troubleshooting fragile Kerberos setup. Mesage {code:java|title=ElytronMessages} @Message(id = 1121, value = "Unable to perform initial JAAS login.") GeneralSecurityException unableToPerformInitialLogin(@Cause LoginException cause); {code} is created in {code:java|title=GSSCredentialSecurityFactory.java#L283} } catch (LoginException e) { throw log.unableToPerformInitialLogin(e); } {code} and logged into log by {code:java|title=ServerAuthenticationContext.java#L847} } catch (GeneralSecurityException e) { // skip this credential log.trace(e); } {code} An more importantly. Question here is if some global issue should follow up? Because problem is in usage of log.trace(e) where although cause exception is avalaible, effectivelly is called log.trace(e.toString()) and cause is hidden; So probably some global check should be performed in elytron codebase if other such occurences aren't also problematic. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8202) CS tool, format Missing required option

by Ilia Vassilev (JIRA)

[ https://issues.jboss.org/browse/WFLY-8202?page=com.atlassian.jira.plugin.... ] Ilia Vassilev commented on WFLY-8202: ------------------------------------- [~mchoma] The message is formatted by Apache cli lib and it is standard for such tools (see [1]). [1] http://grepcode.com/file/repo1.maven.org/maven2/commons-cli/commons-cli/1... > CS tool, format Missing required option > --------------------------------------- > > Key: WFLY-8202 > URL: https://issues.jboss.org/browse/WFLY-8202 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Martin Choma > Assignee: Ilia Vassilev > Labels: credential-store, user_experience, wildfly-elytron-tool > > There is validation on required option. > {code} > [mchoma@localhost bin]$ java -jar wildfly-elytron-tool.jar credential-store > Missing required option: [-a Add new alias to the credential store, -r Remove alias from the credential store, -e Check if alias exists within the credential store, -v Display all aliases, -h Get help with usage of this command][mchoma@localhost bin]$ > {code} > However it is one line message. I would prefer mulitline message for readability as > {code} > [mchoma@localhost bin]$ java -jar wildfly-elytron-tool.jar credential-store > Missing one of required options: > -a Add new alias to the credential store, > -r Remove alias from the credential store, > -e Check if alias exists within the credential store, > -v Display all aliases, > -h Get help with usage of this command > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ELY-989) Create tests for AuthenticationContext

by Ondrej Lukas (JIRA)

Ondrej Lukas created ELY-989: -------------------------------- Summary: Create tests for AuthenticationContext Key: ELY-989 URL: https://issues.jboss.org/browse/ELY-989 Project: WildFly Elytron Issue Type: Bug Components: Testsuite Affects Versions: 1.1.0.Beta28 Reporter: Ondrej Lukas Assignee: Ondrej Lukas -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ELY-988) Methods 'replacing' and 'replacingSslContext' in AuthenticationContext work incorrectly

by Ondrej Lukas (JIRA)

[ https://issues.jboss.org/browse/ELY-988?page=com.atlassian.jira.plugin.sy... ] Ondrej Lukas updated ELY-988: ----------------------------- Affects Version/s: 1.1.0.Beta28 > Methods 'replacing' and 'replacingSslContext' in AuthenticationContext work incorrectly > --------------------------------------------------------------------------------------- > > Key: ELY-988 > URL: https://issues.jboss.org/browse/ELY-988 > Project: WildFly Elytron > Issue Type: Bug > Affects Versions: 1.1.0.Beta28 > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > Priority: Critical > > According to their javadoc, these methods should replace the rule and configuration (or SSL context) at the given index with the given rule and configuration. > In case when AuthenticationContext is defined with RuleNode - RuleA, RuleB, RuleC and RuleNode {{replacing}} method is called for index1 and RuleD, then: > * correct behavior should be - new AuthenticationContext with rule ordered - RuleA, RuleD, RuleC is created > * current behavior is - new AuthenticationContext with rule ordered - RuleD, RuleD, RuleB RuleC is created > Behavior of these methods is correct only in case when they are called with index 0. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ELY-988) Methods 'replacing' and 'replacingSslContext' in AuthenticationContext work incorrectly

by Ondrej Lukas (JIRA)

Ondrej Lukas created ELY-988: -------------------------------- Summary: Methods 'replacing' and 'replacingSslContext' in AuthenticationContext work incorrectly Key: ELY-988 URL: https://issues.jboss.org/browse/ELY-988 Project: WildFly Elytron Issue Type: Bug Reporter: Ondrej Lukas Assignee: Darran Lofthouse Priority: Critical According to their javadoc, these methods should replace the rule and configuration (or SSL context) at the given index with the given rule and configuration. In case when AuthenticationContext is defined with RuleNode - RuleA, RuleB, RuleC and RuleNode {{replacing}} method is called for index1 and RuleD, then: * correct behavior should be - new AuthenticationContext with rule ordered - RuleA, RuleD, RuleC is created * current behavior is - new AuthenticationContext with rule ordered - RuleD, RuleD, RuleB RuleC is created Behavior of these methods is correct only in case when they are called with index 0. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1461) In operator doesn't work with variable

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1461?page=com.atlassian.jira.plugi... ] Mario Fusco resolved DROOLS-1461. --------------------------------- Resolution: Rejected > In operator doesn't work with variable > -------------------------------------- > > Key: DROOLS-1461 > URL: https://issues.jboss.org/browse/DROOLS-1461 > Project: Drools > Issue Type: Bug > Components: core engine > Reporter: Anton Giertli > Assignee: Mario Fusco > Attachments: operators.zip, screenshot-1.png > > > This works just fine: > {code:java} > rule "checkFirstName" > dialect "mvel" > when > Message( message in ( "anton","giertli") ) > then > System.out.println("LHS OK"); > end > {code} > But rule like this, won't fire: > {code:java} > global java.util.List $myGlobal; > rule "checkFirstName" > dialect "mvel" > when > Message( message in ( $myGlobal) ) > then > System.out.println("LHS OK"); > end > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira March 2017