Rudder

With current logs, it is quite hard to understand if and how an authentication backend failed, and if so, that a fallback was used (and failed).

Typically, when the default authentication is on LDAP and file second, if an user is missing from LDAP, we get logs like:

[2021-11-03 11:26:23+0100] ERROR application - Invalid password format: not a Bcrypt string
[2021-11-03 11:26:23+0100] WARN  application - Login authentication failed for user 'xxx' from IP '127.0.0.1|X-Forwarded-For:10.243.4.188': Bad credentials

We need at least DEBUG level to understand (with added comments starting by #)

# failing on one DaoAuthenticationProvider, likely built-in root users, of course login does not matches
[2021-11-05 10:39:40+0100] DEBUG org.springframework.security.authentication.dao.DaoAuthenticationProvider - User 'xxx' not found
# starting LDAP authentication
[2021-11-05 10:39:40+0100] DEBUG org.springframework.security.ldap.authentication.LdapAuthenticationProvider - Processing authentication request for user: xxx
[2021-11-05 10:39:40+0100] DEBUG org.springframework.security.ldap.search.FilterBasedLdapUserSearch - Searching for user 'xxx', with user search [ searchFilter: '(&(uid={0})(objectclass=posixAccount))', searchBase: '', scope: subtree, searchTimeLimit: 0, derefLinkFlag: false ]
[2021-11-05 10:39:40+0100] DEBUG org.springframework.security.ldap.SpringSecurityLdapTemplate - Searching for entry under DN 'ou=users,dc=foo,dc=fr', base = '', filter = '(&(uid={0})(objectclass=posixAccount))'
# here, LDAP didn't find anything, so we fallback on next backend: file based. 
# This one fails because the password is not a bcrypt one - of course, but the message is... cryptic.
[2021-11-05 10:39:41+0100] ERROR application - Invalid password format: not a Bcrypt string
# AH! only now we understand that we were trying a DaoAuthenticationProvider (ie file based list of user)
[2021-11-05 10:39:41+0100] DEBUG org.springframework.security.authentication.dao.DaoAuthenticationProvider - Authentication failed: password does not match stored value
# we tested all rudder auth backend, now debug is only for spring security other things.
[2021-11-05 10:39:41+0100] DEBUG org.springframework.security.web.authentication.UsernamePasswordAuthenticationFilter - Authentication request failed: bootstrap.liftweb.RudderProviderManager$1: Bad credentials
[2021-11-05 10:39:41+0100] DEBUG org.springframework.security.web.authentication.UsernamePasswordAuthenticationFilter - Updated SecurityContextHolder to contain null Authentication
[2021-11-05 10:39:41+0100] DEBUG org.springframework.security.web.authentication.UsernamePasswordAuthenticationFilter - Delegating to authentication failure handler bootstrap.liftweb.RudderUrlAuthenticationFailureHandler@2d16f05
[2021-11-05 10:39:41+0100] WARN  application - Login authentication failed for user 'xxx' from IP '127.0.0.1|X-Forwarded-For:10.243.4.188': Bad credentials
[2021-11-05 10:39:41+0100] DEBUG org.springframework.security.web.DefaultRedirectStrategy - Redirecting to '/rudder/index.html?login_error=true'

So, we would like something like:

[info] authentication request for user 'xxx'
# no need to put a first message for the default auth, we know it will be tried
[info] 'xxx': failed authentication request on 'ldap' backend 
[info] 'xxx': failed authentication request on 'file' backend 
[warn] application - Login authentication failed for user 'xxx' from IP '127.0.0.1|X-Forwarded-For:10.243.4.188': Bad credentials

Tech note: unfortunately, the auth framework (spring security) does not allow these changes, and after 2h trying to understand how it could be done, I failed. It would need 1d of work to really understand what is going on and how to change it.