Having a customized LDAP authentication management, I had to override the A12 method “authenticateLocal” in the following way :
public AbstractExtendedUser<?> authenticateLocal(final String userName, final String rawPassword) {
final LocalUser localUser = localUserManager.findLocalUser(userName);
if (!encrypterService.tryDecodeBase64(localUser.getPassword()).equals(rawPassword)) {
throw new BadCredentialsException(String.format("Invalid credentials for %s", userName));
}
return localUserManager.createUser(userName);
}
However, our customer wants failed logins not to be logged as “errors” anymore, but as “infos” in the logs. If I replace the BadCredentialsException with “null” and add a Log.info-statement, the user is granted access to the UI by A12. I have the impression that this exception most always be thrown if you don´t want the user to log in? Or how can I refuse the user access, but at the same time just write an “info-” statement in the logs?
Hi,
would following be sufficient?
public AbstractExtendedUser<?> authenticateLocal(final String userName, final String rawPassword) {
final LocalUser localUser = localUserManager.findLocalUser(userName);
// Check for null values
if (localUser == null || localUser.getPassword() == null) {
logger.info("Authentication failed: User {} not found or password is null.", userName);
throw new BadCredentialsException("Invalid credentials for " + userName);
}
// Verify password
if (!encrypterService.tryDecodeBase64(localUser.getPassword()).equals(rawPassword)) {
logger.info("Invalid credentials for user: {}", userName); // Log at info level
throw new BadCredentialsException("Invalid credentials for " + userName);
}
// If authentication succeeds
return localUserManager.createUser(userName);
}
If I understand BadCredentialsException constructor correctly passing null as argument should not lead to succesful login.
@tuan-stable-gale , can you please have a look at this?
Hello @josef-brisk-cache ,
thanks for answering 
The thing is that we don´t want an error/exception to appear in the log when someone can´t log in:
We only want the “info” statement but no error. The reason is, because our admins collect the error statements from our logs which appear in the monitoring and we don´t want an error to shop up in the monitoring everytime someone fails to login.
I see,
would it be possible not to throw this exception at all?
public AbstractExtendedUser<?> authenticateLocal(final String userName, final String rawPassword) {
final LocalUser localUser = localUserManager.findLocalUser(userName);
// Check for null values
if (localUser == null || localUser.getPassword() == null) {
logger.info("Authentication failed: User {} not found or password is null.", userName);
}
// Verify password
if (!encrypterService.tryDecodeBase64(localUser.getPassword()).equals(rawPassword)) {
logger.info("Invalid credentials for user: {}", userName); // Log at info level
}
// If authentication succeeds
return localUserManager.createUser(userName);
}
No, because then the last line “return localUser…” would always authenticate in the end. But even if I return “null” under the “logger.info” statements, an error is thrown:
public AbstractExtendedUser<?> authenticateLocal(final String userName, final String rawPassword) {
final LocalUser localUser = localUserManager.findLocalUser(userName);
// Check for null values
if (localUser == null || localUser.getPassword() == null) {
log.info("Authentication failed: User {} not found or password is null.", userName);
return null;
}
// Verify password
if (!encrypterService.tryDecodeBase64(localUser.getPassword()).equals(rawPassword)) {
log.info("Invalid credentials for user: {}", userName); // Log at info level
return null;
}
// If authentication succeeds
return localUserManager.createUser(userName);
}
So basically the function authenticateLocal forces me to return a user which is able to authenticate or an error must be thrown in the log.
You re right. You would need to return always.
I reached out to UAA guys to have a look.
btw in one project I have found this:
throw new BadCredentialsException("");
hello @werther-veiled-cliff ,
I have a look at the code and we don’t have a quick solution to help you now.
Either you throws exception or you return a property principal for security context (success login).
Please create a requirement ticket for us to have a look deeper in the solution for you.
Thanks,
Tuan Do
Hello @tuan-stable-gale and thank you
I will write a requirement ticket. As a workaround I´ve suppressed the logging from the responsible package by adding
logging.level.com.mgmtp.a12.uaa.authentication.local.internal: OFF
to the application.properties.
However, I still receive the following error which I can´t fix since I can´t really alter the A12 library code much
[http-nio-9093-exec-1]2025-02-26 13:21:36 ERROR o.a.c.c.C.[.[.[.[dispatcherServlet]#log - Servlet.service() for servlet [dispatcherServlet] in context with path [] threw exception
java.lang.IllegalArgumentException: You have entered a password with no PasswordEncoder. If that is your intent, it should be prefixed with `{noop}`.
at org.springframework.security.crypto.password.DelegatingPasswordEncoder$UnmappedIdPasswordEncoder.matches(DelegatingPasswordEncoder.java:296)
at org.springframework.security.crypto.password.DelegatingPasswordEncoder.matches(DelegatingPasswordEncoder.java:241)
at org.springframework.security.authentication.dao.DaoAuthenticationProvider.additionalAuthenticationChecks(DaoAuthenticationProvider.java:90)
at org.springframework.security.authentication.dao.AbstractUserDetailsAuthenticationProvider.authenticate(AbstractUserDetailsAuthenticationProvider.java:147)
at org.springframework.security.authentication.ProviderManager.authenticate(ProviderManager.java:182)
at org.springframework.security.authentication.ProviderManager.authenticate(ProviderManager.java:201)
at org.springframework.security.authentication.ObservationAuthenticationManager.lambda$authenticate$1(ObservationAuthenticationManager.java:54)
at io.micrometer.observation.Observation.lambda$observe$4(Observation.java:544)
at io.micrometer.observation.Observation.observeWithContext(Observation.java:603)
at io.micrometer.observation.Observation.observe(Observation.java:544)
at org.springframework.security.authentication.ObservationAuthenticationManager.authenticate(ObservationAuthenticationManager.java:53)
at com.mgmtp.a12.uaa.authentication.security.login.internal.UAAAuthenticationFilter.attemptAuthentication(UAAAuthenticationFilter.java:59)
at org.springframework.security.web.authentication.AbstractAuthenticationProcessingFilter.doFilter(AbstractAuthenticationProcessingFilter.java:231)
Is there any way I can get rid off this error?
Hi @werther-veiled-cliff ,
If you want to get rid of this error from spring, currently I would recommend you to create a custom PrincipalFactory which is responsible for initiating the UserDetail instance. The notable thing here is you need to set the password of the UserDetail into “{noop}” (it is “”***" by default and is the reason of the error, we might improve it in the future). Let check the example below.
public class CustomPrincipalFactory implements PrincipalFactory {
@SuppressWarnings("unchecked")
@Override
public <T extends AbstractExtendedPrincipal<?>> T createPrincipal(String userName, Collection<? extends GrantedAuthority> authorities) {
return (T) createPrincipal(userName, "{noop}", authorities, null);
}
@SuppressWarnings("unchecked")
@Override
public <T extends AbstractExtendedPrincipal<?>> T createPrincipal(String userName, String password, Collection<? extends GrantedAuthority> authorities,
Object extendedUserData) {
ExtendedPrincipal user = new ExtendedPrincipal(userName, "{noop}", authorities, extendedUserData);
return (T) user;
}
}
The Other option is creating a bean of PasswordEncoder like:
@Bean
public PasswordEncoder encoder() {
return new BCryptPasswordEncoder(11);
}
Note that this bean might be useless with your business but it helps to by pass the error.
I don’t recommend to disable the log here because the class conducts the error log here is the dispatcherservlet which is the very low level code to disable the logging.
Requirement ticket created : A12-17142
Requirement ticket was closed.
