Skip to content

Authentication Mechanisms Should Default their ServerSecurityContextRepository #7249

Closed
@jzheaux

Description

@jzheaux

The Javadoc for ServerHttpSecurity#securityContextRepository states:

The strategy used with {@code ReactorContextWebFilter}. It does not impact how the {@code SecurityContext} is saved which is configured on a per {@link AuthenticationWebFilter} basis.

This is, however, outdated since form login does use this value if it's specified by the application:

if (this.securityContextRepository != null) {
	this.formLogin.securityContextRepository(this.securityContextRepository);
}

I had a chat with @rwinch, and the desired functionality is the following:

If an application wires a security context repository for a given authentication mechanisms, that takes precedence for that mechanism. For example:

http
    .securityContextRepository(a)
    .formLogin()
        .securityContextRepository(b);
http
    .formLogin()
        .securityContextRepository(b);

In both cases, b would be used for form login.

If not, then, the authentication mechanism should use the global one:

http
    .securityContextRepository(a)
        .formLogin();

In this case, a would be used for form login.

If none is specified by the application, each authentication mechanisms should use what it already defaults to.

So, to complete this task, there are three steps:

  1. Update the logic in form login, which currently accepts the global value regardless
  2. Update the logic in http basic and oauth2 login, which currently don't consider the global value at all
  3. Update the JavaDoc to indicate that setting the securityContextRepository does affect the underlying authentication mechanisms.

Metadata

Metadata

Assignees

Labels

in: webAn issue in web modules (web, webmvc)type: enhancementA general enhancement

Type

No type

Projects

No projects

Milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions