[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 reassigned WFLY-8286:
---------------------------------
Assignee: David Lloyd (was: Darran Lofthouse)
> 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: David Lloyd
> 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)
7 years, 4 months
[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:
-----------------------------------
Going to expand on this a little.
If there is no credential which matches the parameters in the callback, that's fine: the callback is still supported and we should return without setting the credential. Then the mech might know to try another option.
If there *is* a matching credential, then if acquiring the credential fails, it's probably going to be a fatal auth problem. If it turns out I'm wrong, we can still move to the accumulate/addSuppressed strategy I described before.
> 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)
7 years, 4 months
[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)
7 years, 4 months
[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)
7 years, 4 months
[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)
7 years, 4 months
[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)
7 years, 4 months
[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)
7 years, 4 months
[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)
7 years, 4 months
[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)
7 years, 4 months