Skip to content

Authentication Mechanisms Should Default their ServerSecurityContextRepository #7249

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
jzheaux opened this issue Aug 10, 2019 · 2 comments · Fixed by #7275
Closed

Authentication Mechanisms Should Default their ServerSecurityContextRepository #7249

jzheaux opened this issue Aug 10, 2019 · 2 comments · Fixed by #7275
Assignees
Labels
in: web An issue in web modules (web, webmvc) type: enhancement A general enhancement
Milestone

Comments

@jzheaux
Copy link
Contributor

jzheaux commented Aug 10, 2019

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.
@jzheaux jzheaux added in: oauth2 An issue in OAuth2 modules (oauth2-core, oauth2-client, oauth2-resource-server, oauth2-jose) status: ideal-for-contribution An issue that we actively are looking for someone to help us with type: enhancement A general enhancement in: web An issue in web modules (web, webmvc) and removed in: oauth2 An issue in OAuth2 modules (oauth2-core, oauth2-client, oauth2-resource-server, oauth2-jose) labels Aug 16, 2019
@jzheaux jzheaux added this to the 5.2.0.RC1 milestone Aug 16, 2019
@eddumelendez
Copy link
Contributor

I will take a look at this one @jzheaux

@jzheaux
Copy link
Contributor Author

jzheaux commented Aug 17, 2019

Sounds great, @eddumelendez, it's yours.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: web An issue in web modules (web, webmvc) type: enhancement A general enhancement
Projects
None yet
2 participants