Support customizing the redirect URL in OidcClientInitiatedServerLogoutSuccessHandler #14778

stipx · 2024-03-19T09:55:32Z

Expected Behavior

In order to be able to work with some restrictive SSO implementations sometimes additional parameters are needed (like "state") in order that the logout request is succeeding.

Current Behavior

In order to achieve this it was necessary to implement a custom logout handler which gets the logout/end_session URL from the client registration and sets the ID-Token hint, the redirect uri and the state and does a redirect then.

So a simple resolver/converter/customizer for the redirect URL would be much easier than implementing a whole new logout handler.

programista-zacny · 2024-03-20T07:26:22Z

I agree.

We needed to redirect to dynamic url when OIDC logout. location query param was used.
E.g. /logout?location=http://somewhere.com

@RequiredArgsConstructor
public class RedirectOidcServerLogoutSuccessHandler implements ServerLogoutSuccessHandler {

    private final ReactiveClientRegistrationRepository clientRegistrationRepository;

    @Override
    public Mono<Void> onLogoutSuccess(WebFilterExchange exchange, Authentication authentication) {
        OidcClientInitiatedServerLogoutSuccessHandler delegate =
                new OidcClientInitiatedServerLogoutSuccessHandler(clientRegistrationRepository);
        getLocation(exchange).ifPresent(delegate::setPostLogoutRedirectUri);
        return delegate.onLogoutSuccess(exchange, authentication);
    }

    private Optional<String> getLocation(WebFilterExchange exchange) {
        return Optional.ofNullable(exchange.getExchange().getRequest().getQueryParams().getFirst("location"));
    }
}

…InitiatedServerLogoutSuccessHandler Closes spring-projectsgh-14778

CrazyParanoid · 2024-03-27T10:05:10Z

I can suggest a simple solution - add setServerLogoutSuccessHandler. This will allow you to implement your RedirectServerLogoutSuccessHandler and pass it to OidcClientInitiatedServerLogoutSuccessHandler, for example:

    public class RedirectOidcServerLogoutSuccessHandler extends RedirectServerLogoutSuccessHandler {

        private final ReactiveClientRegistrationRepository clientRegistrationRepository;

        public RedirectOidcServerLogoutSuccessHandler(ReactiveClientRegistrationRepository clientRegistrationRepository) {
            this.clientRegistrationRepository = clientRegistrationRepository;
        }

        @Override
        public Mono<Void> onLogoutSuccess(WebFilterExchange exchange, Authentication authentication) {
            OidcClientInitiatedServerLogoutSuccessHandler delegate =
                    new OidcClientInitiatedServerLogoutSuccessHandler(clientRegistrationRepository);
            getLocation(exchange).ifPresent(delegate::setPostLogoutRedirectUri);
            return delegate.onLogoutSuccess(exchange, authentication);
        }

        private Optional<String> getLocation(WebFilterExchange exchange) {
            return Optional.ofNullable(exchange.getExchange().getRequest().getQueryParams().getFirst("location"));
        }
    }

Then:

OidcClientInitiatedServerLogoutSuccessHandler handler = new OidcClientInitiatedServerLogoutSuccessHandler(this.repository);
handler.setServerLogoutSuccessHandler(new RedirectOidcServerLogoutSuccessHandler(repository));

jzheaux · 2024-04-01T17:08:45Z

While a clever solution, @CrazyParanoid, I think it would be preferable to align with the imperative component in this case and have a protected method. While it's rare in Spring Security to open a method up for overriding, delegation in this case requires a bit of gymnastics since it is not possible to operate on the return object.

Instead of setServerLogoutSuccessHandler, what if we did this:

protected Mono<String> determineLogoutUri(WebFilterExchange exchange, Authentication authentication) {
    return this.clientRegistrationRepository::findByRegistrationId).flatMap((clientRegistration) -> {
		URI endSessionEndpoint = endSessionEndpoint(clientRegistration);
		if (endSessionEndpoint == null) {
			return Mono.empty();
		}
		String idToken = idToken(authentication);
		String postLogoutRedirectUri = postLogoutRedirectUri(exchange.getExchange().getRequest(), clientRegistration);
		return Mono.just(endpointUri(endSessionEndpoint, idToken, postLogoutRedirectUri));
    });
}

Then, an application can override this method to change the URI dynamically.

jzheaux · 2024-04-01T20:23:53Z

@CrazyParanoid and @programista-zacny, I'm sorry. I should have looked at your proposal more carefully. Redirecting to a location specified in a query parameter is not advised as this is vulnerable to open redirect. You should not redirect to a location that a client can arbitrarily specify, say through a request parameter like location.

Instead, the locations to which you can redirect should be something that the server controls. Before proceeding, then, I'd like to understand better what you are trying to do. This will ensure that we don't add a feature for an insecure reason.

CrazyParanoid · 2024-04-01T20:33:25Z

Hi @jzheaux this is a very interesting solution. I considered this solution, but I was confused by the fact that such an implementation is rarely found in the spring security API and developers are mostly accustomed to work with lambda-based factories. Maybe we should try to find such a solution? We can extract the logic for determining the URL to lambda-factory

	private class DefaultLogoutUriFactory implements BiFunction<WebFilterExchange,Authentication, Mono<String>> {

		@Override
		public Mono<String> apply(WebFilterExchange exchange, Authentication authentication) {
			return Mono.just(authentication)
					.filter(OAuth2AuthenticationToken.class::isInstance)
					.filter((token) -> authentication.getPrincipal() instanceof OidcUser)
					.map(OAuth2AuthenticationToken.class::cast)
					.map(OAuth2AuthenticationToken::getAuthorizedClientRegistrationId)
					.flatMap(clientRegistrationRepository::findByRegistrationId)
					.flatMap((clientRegistration) -> {
						URI endSessionEndpoint = endSessionEndpoint(clientRegistration);
						if (endSessionEndpoint == null) {
							return Mono.empty();
						}
						String idToken = idToken(authentication);
						String postLogoutRedirectUri = postLogoutRedirectUri(exchange.getExchange().getRequest(), clientRegistration);
						return Mono.just(endpointUri(endSessionEndpoint, idToken, postLogoutRedirectUri));
					});
		}
	}

Then we define:

private BiFunction<WebFilterExchange,Authentication, Mono<String>> logoutUriFactory = new DefaultLogoutUriFactory();

@Override
public Mono<Void> onLogoutSuccess(WebFilterExchange exchange, Authentication authentication) {
	return logoutUriFactory.apply(exchange, authentication)
				.switchIfEmpty(
						this.serverLogoutSuccessHandler.onLogoutSuccess(exchange, authentication).then(Mono.empty())
				)
				.flatMap((endpointUri) -> this.redirectStrategy.sendRedirect(exchange.getExchange(), URI.create(endpointUri)));
}

public void setLogoutUriFactory(BiFunction<WebFilterExchange, Authentication, Mono<String>> logoutUriFactory) {
     Assert.notNull(serverLogoutSuccessHandler, "logoutUriFactory cannot be null");
     this.logoutUriFactory = logoutUriFactory;
}

Now you can easily determine the URL:

this.handler.setLogoutUriFactory((ex, auth) -> Mono.just(
				Objects.requireNonNull(
						ex.getExchange()
								.getRequest()
								.getQueryParams()
								.getFirst("location")
				)
		));

What do you think about this solution?

CrazyParanoid · 2024-04-01T20:42:48Z

@jzheaux I agree it looks unsafe. @stipx said: "In order to be able to work with some restrictive SSO implementations sometimes additional parameters are needed (like "state") in order that the logout request is succeeding." It seems that such implementation resolves this case, but at the same time it can add potential vulnerabilities if the developer is careless.

programista-zacny · 2024-04-02T08:36:02Z

@jzheaux In my case, Keycloak still controls valid redirect urls :)
It's not totally up to user of the logout, it can be somehow "dynamically" but in the end Keycloak will validate if the redirect url is safe (there is a list of valid redirect urls in Keycloak).

jzheaux · 2024-04-17T20:20:09Z

Nice idea, @CrazyParanoid, though, I'd prefer not to expose a BiFunction as it's not as self-documenting and, perhaps more importantly, the same outcome can be achieved with Function and a wrapper object. A wrapper object makes it easier to have more than two parameters and also get the servlet and webflux implementations aligned.

So instead, could we do setRedirectUriResolver(Converter<RedirectUriParameters, Mono<String>>)? RedirectUriParameters would be a static inner class that contains the ServerWebExchange, the Authentication, and the ClientRegistration.

Closes spring-projectsgh-14778

CrazyParanoid · 2024-04-17T22:23:27Z

@jzheaux good solution! I have updated PR.

Closes spring-projectsgh-14778

stipx added status: waiting-for-triage An issue we've not yet triaged type: enhancement A general enhancement labels Mar 19, 2024

CrazyParanoid pushed a commit to CrazyParanoid/spring-security that referenced this issue Mar 27, 2024

Add support customizing the serverLogoutSuccessHandler for OidcClient…

24bae67

…InitiatedServerLogoutSuccessHandler Closes spring-projectsgh-14778

CrazyParanoid linked a pull request Mar 27, 2024 that will close this issue

Add support customizing the serverLogoutSuccessHandler for OidcClientInitiatedServerLogoutSuccessHandler #14808

Open

sjohnr assigned jzheaux Mar 28, 2024

sjohnr added the in: oauth2 An issue in OAuth2 modules (oauth2-core, oauth2-client, oauth2-resource-server, oauth2-jose) label Mar 28, 2024

jzheaux added status: waiting-for-feedback We need additional information before we can continue and removed status: waiting-for-triage An issue we've not yet triaged labels Apr 1, 2024

spring-projects-issues added status: feedback-provided Feedback has been provided and removed status: waiting-for-feedback We need additional information before we can continue labels Apr 1, 2024

jzheaux added status: waiting-for-feedback We need additional information before we can continue and removed status: feedback-provided Feedback has been provided labels Apr 17, 2024

CrazyParanoid pushed a commit to CrazyParanoid/spring-security that referenced this issue Apr 17, 2024

Add support customizing redirect URI

cb06ab0

Closes spring-projectsgh-14778

spring-projects-issues added status: feedback-provided Feedback has been provided and removed status: waiting-for-feedback We need additional information before we can continue labels Apr 17, 2024

CrazyParanoid pushed a commit to CrazyParanoid/spring-security that referenced this issue Apr 25, 2024

Add support customizing redirect URI

6639468

Closes spring-projectsgh-14778

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Support customizing the redirect URL in OidcClientInitiatedServerLogoutSuccessHandler #14778

Support customizing the redirect URL in OidcClientInitiatedServerLogoutSuccessHandler #14778

stipx commented Mar 19, 2024

programista-zacny commented Mar 20, 2024

CrazyParanoid commented Mar 27, 2024

jzheaux commented Apr 1, 2024

jzheaux commented Apr 1, 2024

CrazyParanoid commented Apr 1, 2024 •

edited

CrazyParanoid commented Apr 1, 2024

programista-zacny commented Apr 2, 2024 •

edited

jzheaux commented Apr 17, 2024

CrazyParanoid commented Apr 17, 2024

Support customizing the redirect URL in OidcClientInitiatedServerLogoutSuccessHandler #14778

Support customizing the redirect URL in OidcClientInitiatedServerLogoutSuccessHandler #14778

Comments

stipx commented Mar 19, 2024

programista-zacny commented Mar 20, 2024

CrazyParanoid commented Mar 27, 2024

jzheaux commented Apr 1, 2024

jzheaux commented Apr 1, 2024

CrazyParanoid commented Apr 1, 2024 • edited

CrazyParanoid commented Apr 1, 2024

programista-zacny commented Apr 2, 2024 • edited

jzheaux commented Apr 17, 2024

CrazyParanoid commented Apr 17, 2024

CrazyParanoid commented Apr 1, 2024 •

edited

programista-zacny commented Apr 2, 2024 •

edited