Seeing a weird exception after a successful login

[stevesobol]

Using the latest Quarkus on graalvm-jdk-21.0.4+8.1. Windows 11 23H2, 64-bit, with all the updates, if it matters.

I'm working on a custom SecurityIdentityProvider. I'm trying to get it working with form authentication. Initially I'm just trying to get it working with a predefined username (bob) and password (bob).

package com.example;

import io.quarkus.security.AuthenticationFailedException;
import io.quarkus.security.identity.AuthenticationRequestContext;
import io.quarkus.security.identity.IdentityProvider;
import io.quarkus.security.identity.SecurityIdentity;
import io.quarkus.security.identity.request.UsernamePasswordAuthenticationRequest;
import io.quarkus.security.runtime.QuarkusPrincipal;
import io.quarkus.security.runtime.QuarkusSecurityIdentity;
import io.smallrye.mutiny.Uni;
import jakarta.enterprise.context.ApplicationScoped;

import java.util.Map;

@ApplicationScoped
public class ExampleIdentityProvider implements IdentityProvider<UsernamePasswordAuthenticationRequest> {
    private static final Map<String, String> CREDENTIALS = Map.of("bob", "bob");

    @Override
    public Class<UsernamePasswordAuthenticationRequest> getRequestType() {
        return UsernamePasswordAuthenticationRequest.class;
    }

    @Override
    public Uni<SecurityIdentity> authenticate(UsernamePasswordAuthenticationRequest request,
                                              AuthenticationRequestContext authenticationRequestContext) {
        if (new String(request.getPassword().getPassword()).equals(CREDENTIALS.get(request.getUsername()))) {
			return Uni.createFrom().item(QuarkusSecurityIdentity.builder()
				.setPrincipal(new QuarkusPrincipal(request.getUsername()))
                    .addCredential(request.getPassword())
                    .setAnonymous(false)
                    .addRole("admin")
                    .build());
        }
        throw new AuthenticationFailedException("password invalid or user not found");
    }
}

application.properties looks like this:

quarkus.package.jar.type=uber-jar
quarkus.quinoa.ui-root-path=app
quarkus.quinoa.enable-spa-routing=true

quarkus.http.auth.form.enabled=true
quarkus.http.auth.form.login-page=login
quarkus.http.auth.form.landing-page=success
quarkus.http.auth.form.error-page=error

quarkus.datasource.db-kind=mariadb
quarkus.datasource.username=db-username
quarkus.datasource.password=db-password
quarkus.datasource.jdbc.url=jdbc:mariadb://localhost/somedatabase

Although I am using quinoa for part of the application, the login, success and error pages are standard Qute templates.

I can log in successfully. But instead of seeing the "success" page, I get an exception

java.lang.IllegalArgumentException: No IdentityProviders were registered to handle AuthenticationRequest io.quarkus.security.identity.request.TrustedAuthenticationRequest@326d3217
	at io.quarkus.security.runtime.QuarkusIdentityProviderManagerImpl.authenticate(QuarkusIdentityProviderManagerImpl.java:61)
	at io.quarkus.security.identity.IdentityProviderManagerCreator_ProducerMethod_ipm_kfECvhsqeBIW24qB5qtLmxqE8Dw_ClientProxy.authenticate(Unknown Source)
	at io.quarkus.vertx.http.runtime.security.FormAuthenticationMechanism.authenticate(FormAuthenticationMechanism.java:266)
	at io.quarkus.vertx.http.runtime.security.HttpAuthenticator.createSecurityIdentity(HttpAuthenticator.java:223)
	at io.quarkus.vertx.http.runtime.security.HttpAuthenticator.attemptAuthentication(HttpAuthenticator.java:181)
	at io.quarkus.vertx.http.runtime.security.HttpSecurityRecorder$AuthenticationHandler.handle(HttpSecurityRecorder.java:284)
	at io.quarkus.vertx.http.runtime.security.HttpSecurityRecorder$AuthenticationHandler.handle(HttpSecurityRecorder.java:233)
	at io.vertx.ext.web.impl.RouteState.handleContext(RouteState.java:1285)
	at io.vertx.ext.web.impl.RoutingContextImplBase.iterateNext(RoutingContextImplBase.java:177)
	at io.vertx.ext.web.impl.RoutingContextImpl.next(RoutingContextImpl.java:140)
	at io.quarkus.vertx.http.runtime.devmode.VertxHttpHotReplacementSetup.handleHotReplacementRequest(VertxHttpHotReplacementSetup.java:144)
	at io.quarkus.vertx.http.runtime.VertxHttpRecorder$HotReplacementRoutingContextHandler.handle(VertxHttpRecorder.java:1652)

(many lines of stacktrace omitted)

/restricted points to this method:

	@GET
	@RolesAllowed("admin")
	@Path("/restricted")
	public String me(@Context SecurityContext securityContext) {
		return securityContext.getUserPrincipal().getName();
	}

Any ideas? What am I doing wrong?

[stevesobol]

Incidentally, I know the login is successful. I had a couple lines of code placed before the return in authenticate() and when I logged in successfully, I saw the log entries. The problem seems to occur when my web browser requests /restricted after a successful login.

[sberyozkin]

@stevesobol The problem we were trying to solve here was how to make sure that form authentication applications can only replace only one of the two required identity providers, the one managing name and password, if it has to be customised.

Your reproducer is about something else, why, in case of the wrong password, user is redirected to the default home page...

I guess an error page must be configured

[sberyozkin]

I see it is configured, @michalvavrik , can you please have a quick look next week?

[michalvavrik]

Sure, I'll check.

[mkouba]

AFAIK you always need to implement both IdentityProvider<UsernamePasswordAuthenticationRequest> and IdentityProvider<TrustedAuthenticationRequest> if using form-based authentication. At least that's what quarkus-security-jpa generates and I also used it successfully with my apps. The IdentityProvider<TrustedAuthenticationRequest> implementation is used to authenticate request from an encrypted cookie.

In other words, if an IdentityProvider<UsernamePasswordAuthenticationRequest> succeeds the authentication information is stored in an encrypted cookie which is sent with a follow-up requests and for these requests the IdentityProvider<TrustedAuthenticationRequest> is used to build a SecurityIdentity.

[sberyozkin]

Hi @mkouba Thanks, sure, but if we only register a higher priority IdentityProvider<UsernamePasswordAuthenticationRequest> which is preferred to the built-in IdentityProvider<UsernamePasswordAuthenticationRequest>, the built-in IdentityProvider<TrustedAuthenticationRequest> should still be available ?

[mkouba]

the built-in IdentityProvider should still be available ?

Which built-in IdentityProvider<TrustedAuthenticationRequest> do you have in mind? The reproducer app does not seem to include quarkus-security-jpa, quarkus-security-webauthn or any other extension that would provide such implementation?

[sberyozkin]

@mkouba Oh yes, this must be it, I was under the impression only the first one can to be customized, but if the one for the TrustedAuthenticationRequest depends on the same database table for ex, then it does not really make sense to customize a single one independently of the other one.

@stevesobol Sorry, I was thinking that you may want to customise some username and password preprocessing, assuming the default provider for the TrustedAuthenticationRequest can work with the same data your custom username and password identity provider can. If it is still the case then, as @mkouba pointed out, you'd need to use an extension like quarkus-security-jpa. Otherwise, indeed, both type of providers have to be customized for the form authentication to work. Sorry for the confusion if any

[phillip-kruger]

@sberyozkin ^^^