[
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)