Auto-configure map-based PublicKeyCredentialUserEntityRepository and UserCredentialRepository beans when spring-security-webauthn is on the classpath

[rwinch]

In order for the entire application to use the same repositories it would be nice if Spring Boot would automatically add Auto Configuration for WebAuthn Beans.

If spring-security-webauthn is on the classpath, then defineMapPublicKeyCredentialUserEntityRepository and MapUserCredentialRepository with ConditionalOnBean for PublicKeyCredentialUserEntityRepository and UserCredentialRepository respectively.

[wilkinsona]

On second look, I'm not quite sure that I understand the benefit here. I searched the docs, but only found information about using JDBC-based repositories.

As I understand it, WebAuthnConfigurer will look for PublicKeyCredentialUserEntityRepository and UserCredentialRepository beans. If it doesn't find one, it'll create a default MapPublicKeyCredentialUserEntityRepository or MapUserCredentialRepository that's specific to that configurer. I think this means that applications with multiple security filter chains using passkeys will have multiple repositories. I'm not sure if that comes at a functional cost or if it's solely an efficiency concern. I'm guessing it's the latter as the documentation doesn't mention any need to define the map-based repositories as beans. If it is solely an efficiency concern, I'm not sure that defining beans will necessarily be any better as each bean has a small cost in terms of memory footprint, more candidates to consider when auto-wiring, etc.

If we were to do something in Boot, it might be more compelling to provide built-in support for switching to the JDBC-based repositories. That said, Security could perhaps make this easier by providing a method on WebAuthnConfigurer that takes a JdbcOperations instance and switches from map-based to JDBC-based repositories with a single line of code.

[rwinch]

Thanks @wilkinsona

This isn't about efficiency so much as consistency.

An example of the importance of consistency that users face today is when an application specific user registration page allows creating a passkey at the time of account creation. The application will need to find the correct instance of the repository so that it is used for registration and authentication. This aligns with Boot's behavior of exposing InMemoryUserDetailsManager as a Bean because we want to ensure registration occurs on the same InMemoryUserDetailsManager instance as is used for authentication.

Another example of why this alignment is important is that Spring Security is currently working on conditional MFA. One type of conditional MFA is to only require MFA for users that have a passkey registered. This requires that Spring Security needs to use the same webauthn repository instances across the entire application.

I wouldn't be apposed to supporting auto configuration for JDBC based repositories. However, this is probably a larger story here since I don't think Spring Boot ever auto configures JDBC based repositories for Spring Security. For example, I believe it only auto configures InMemoryUserDetailsManager but not JdbcUserDetailsManager. It also comes with additional considerations like setting up schema, initializing the data, etc. In short, if we want to do this, I think it makes sense to do this separately rather than blocking this issue.

[wilkinsona]

Thanks, Rob. Let's put JDBC to one side for now then.

I wonder if Spring Security could do a bit more here to make things easier for users. That will benefit those whose needs are not met by any auto-configuration that Boot might offer. For example, I wonder if an @Enable… annotation could hide the details of defining the two repository beans. Boot could then auto-configure this annotation.

[rwinch]

Thanks for the response @wilkinsona

Can you please help me better understand your suggestion for how the @Enable...annotation would work? What is the annotation name? Would it only support in memory implementations? If not, how would the other implementations be supported? How would implementation specific properties (some of which are rich objects) be specified? What happens if the beans are already defined?

[wilkinsona]

What is the annotation name?

I'm not sure I have the domain expertise to make meaningful naming suggestions. Perhaps something like @EnableSharedWebAuthnRepositories?

Would it only support in memory implementations?

Perhaps initially. But an attribute could control the type of repositories that are enabled:

@EnableSharedWebAuthnRepositories(type = IN_MEMORY)
@EnableSharedWebAuthnRepositories(type = JDBC)

How would implementation specific properties (some of which are rich objects) be specified?

Perhaps an annotation isn't ideal in that case. I'm not wedded to any particular solution. I'm more interested in improving the usability by whatever means will work best. The goal being to minimise the complexity that a user faces when they're not using Boot or not using its auto-configuration.

What happens if the beans are already defined?

I'd expect a failure in that case. The user shouldn't be using whatever convenience mechanism exists for defining the necessary beans if they've already defined them.

[wilkinsona]

An alternative to an annotation-based approach could be something inspired by things like Spring MVC's WebMvcConfigurer callback. Security could provide a WebAuthnConfigurer callback that provides an API for configuring app-wide WebAuthn settings.

[rwinch]

I share your desire to improve the way things are configured within Spring Security and not need to rely on auto configuration. However, at least for now, auto configuration is the status quo for how to work around some of the limitations within Spring Java Configuration

NOTE: The issue is marked as resolved and my original request is now being tracked by spring-projects/spring-framework#21497 However, my original request best describes the missing functionality needed by Spring Security.

Adding auto configuration for these two beans will drastically improve the Spring Security user's getting started experience.