"Sign out" link logs you out of app, but not OIDC

[frank8559]

Overview of the issue

Hello,
I just submit issues related to a keycloak, i don't know if they are related.

Reproduce the error

Launch of associated services via docker-composer (posgres, kafka, zookeeper, elasticsearch, keycloak, consul-config-loader)
use of an external consul
the gateway and the microservice are started via mvnw.
yarn start is also launched for the gateway

1. When we log in via keycloak we are redirected to the gateway.
   Then we logout. if we do F5 we are automatically login.
   If you are on an admin page when you disconnect, you are automatically reconnected (tested with admin and user accounts).

2. problem certainly linked to the issue 1. we connect to a private browser window and we login.
   Open a second private browser window, we are already login.

3. Then if you change the configuration of the url (in the file application.yml), replacing localhost with the ip of the machine (or fqdn), keycloak mark invalid parameter: redirect_ui insteadof login page

summary of issue 3

URL gateway access	keycloak status	results
localhost: 8080	OK	OK
localhost: 9000	OK - KO we are redirected to localhost: 8080
XXX.XXX.XXX.XXX:8080	Invalid parameter: redirect_uri	KO can not authenticate
XXX.XXX.XXX.XXX:9000	Invalid parameter: redirect_uri	KO can not authenticate
fqdn: 8080	Invalid parameter: redirect_uri	KO can not authenticate-
fqdn: 9000	Invalid parameter: redirect_uri	KO can not authenticate

JHipster Version(s)

4.10

Browsers and Operating System

Windows, linux
Tested on firefox 54 and chrome 61

sorry for my english

thanks

[mraible]

We haven't implemented global logout so the automatic login after you've done it once is expected. This is they way most Identity Providers work. If you login to a site with Facebook, logging out of that site doesn't log you out of Facebook. If it did, you'd likely be annoyed.

As far as localhost vs the IP - you'll need to login to Keycloak to change the allowed redirect URI, or modify src/main/docker/config/realm-config/jhipster-realm.json#L1084 to allow your IP.

[frank8559]

Ok
But if I disconnect from a site, I expect to be really logout from this site. no ?
What is the value of the disconnect button?
At work, the accounts 'administration' and 'current use' are separated. how, with keycloak, we switch account?

It's OK for issue 3, the error is really not very clear but it works after the suggested changes. thank you

[mraible]

If you use Chrome in incognito mode, you can switch accounts pretty easily. If that doesn't work, you can visit Keycloak and logout from it, just like you'd logout from Facebook.

Spring Security 5 has better OIDC support, so it might be possible to configure logout using it. It's scheduled for release in early November.

[frank8559]

I test with chrome 61 in incognito mode and I am automatically log in ..
Switch to keycloak to disconnect is not very user friendly (in my opinion)
So the disconnected button should not be deleted? because it is very disturbing!

[mraible]

@frank8559 I renamed the title of this issue. I think it's worthing keeping this issue open until we figure out a solution that allows you to (optionally) logout of the IdP too.

NOTE: Clicking "Sign out" in a monolith app does log you out. If you refresh the page, you're not automatically logged in. It's only when you click "sign in" that you're logged in again. FYI @danielpetisme.

[deepu105]

@mraible I'm not sure if we should be logging out of the IdP. IMHO it's not our scope. This is how most Idp and other SSO work. If I have google logged in I automatically get logged in when I visit any google app (unless I use Incognito) and it provides the global log out and not app vice logout. Probably we should remove the logout option from the app and just point it to the logout page of the Idp. WDYT?

[danielpetisme]

The IdP I knows don't log you out when you logout from the application because it maintains a session on its side. Usually you get a message inviting you to close your browser to be fully logged off. There is a logout feature on keycloak to invalidate the current access token. I Guess there is an API for that we could Request. Le 18 oct. 2017 6:17 PM, "Deepu K Sasidharan" <notifications@github.com> a écrit :

…

@mraible <https://github.com/mraible> I'm not sure if we should be logging out of the IdP. IMHO it's not our scope. This is how most Idp and other SSO work. If I have google logged in I automatically get logged in when I visit any google app (unless I use Incognito) and it provides the global log out and not app vice logout. Probably we should remove the logout option from the app and just point it to the logout page of the Idp. WDYT? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#6555 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAkOnHsS4IuAlS3UkOb5u--ZRIyWeIMoks5stjKogaJpZM4P9iI9> .

[antarus]

I think frank want that when it clicks on disconnect, the user is really disconnecting from its front end and does not reconnect without reentering login / password when it does F5.
As is apparently the case with a monolyth application.
Maybe I'm wrong, but after test, it is true that this behavior is surprising.

[frank8559]

I will like same behavior as the monolith Application

[mraible]

It sounds like the issue here is that microservices logs in again automatically, whereas a monolith works as expected.

OIDC does support an "end session endpoint" - see the bottom of my https://dev-158606.oktapreview.com/oauth2/default/.well-known/openid-configuration. You could call this if you really wanted to logout of your IdP on logout. However, I think the default behavior (stay logged in to the IdP) is the correct one.

FWIW, here's some information on implementing Logout with Spring Security OAuth.

• http://www.baeldung.com/logout-spring-security-oauth
• https://stackoverflow.com/questions/21987589/spring-security-how-to-log-out-user-revoke-oauth2-token

[sendilkumarn]

GIA I guess there was way with invalidate the session using handleinterceptor there was an github issue too for this in spring-security. Let me search that

[Edited] this one

[jdubois]

Yes as @mraible says it's the correct behavior: you did logout from the app, but as you are still connected to the OIDC provider, it will automatically log you in again if you refresh the browser.
Now I understand you want to have a "complete logout" and the solution is provided above by @mraible - that's something we should do, but at the moment let's first finish the opened tickets on OIDC. We have a number of annoying bugs, and they are more important than new features.

[frank8559]

I understand that it's a new feature to disconnect from idp and that you have things more urgent to adjust.
However since the logout button does not fulfill its role, why not remove it from the ihm?
Even without F5, I log in again as soon as I click on a gateway link.

[jdubois]

I just worked on this for a client this morning: I totally confirm the issue. It shouldn't be too hard to solve, that's a good use case for a simple PR. If anyone is interested, please comment!

[jdubois]

I'm doing this

[jdubois]

In fact this is originally a bug. The code calls a "logout" URL which doesn't exists, so that does a 404 error. I just implemented it and it's working:

• You can log out of the app, but still be logged in OIDC
• If you are logged in OIDC and click on "sign in", you are automatically logged in
• If you logged out of OIDC and click on "sign in", you need to log in again

[mraible]

This is how the monolith impl works too. FWIW, I developed an app with pac4j this week and it's OIDC support supports a global logout. The URL for logout from the IdP is included in the ./well-known/openid-configuration file.

…

On Oct 26, 2017, at 07:21, Julien Dubois ***@***.***> wrote: In fact this is originally a bug. The code calls a "logout" URL which doesn't exists, so that does a 404 error. I just implemented it and it's working: You can log out of the app, but still be logged in OIDC If you are logged in OIDC and click on "sign in", you are automatically logged in If you logged out of OIDC and click on "sign in", you need to log in again — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[jdubois]

I'm sorry @mraible but the method was also missing in the monolith, so you add 404 errors when trying to log out - can you check my commit? maybe there's something I don't understand

[mraible]

I just tried generating a monolith with v4.10.1 and there's no 404 when logging out.

[jdubois]

You are correct... But where does this "/api/logout" mapping comes from? We don't have it in the gateway, and I can't find where it's coded

[mraible]

It's configured in SecurityConfiguration.java

@Override
protected void configure(HttpSecurity http) throws Exception {
    http
        .csrf()
        .csrfTokenRepository(CookieCsrfTokenRepository.withHttpOnlyFalse())
    .and()
        .addFilterBefore(corsFilter, CsrfFilter.class)
        .exceptionHandling()
        .authenticationEntryPoint(problemSupport)
        .accessDeniedHandler(problemSupport)
    .and()
        .logout()
        .logoutUrl("/api/logout")
        .logoutSuccessHandler(ajaxLogoutSuccessHandler())
        .permitAll()
    .and()
        .headers()
        .frameOptions()
        .disable()
    .and()
        .authorizeRequests()
        .antMatchers("/api/profile-info").permitAll()
        .antMatchers("/api/**").authenticated()
        .antMatchers("/management/health").permitAll()
        .antMatchers("/management/**").hasAuthority(AuthoritiesConstants.ADMIN)
        .antMatchers("/v2/api-docs/**").permitAll()
        .antMatchers("/swagger-resources/configuration/ui").permitAll()
        .antMatchers("/swagger-ui/index.html").hasAuthority(AuthoritiesConstants.ADMIN);
}

[jdubois]

OK thanks, I'm reverting my commit, and doing the same config in the gateway

[mraible]

Regarding global logout, the .well-known/openid-configuration for Keycloak does contain a URL to logout.

// 20171026083926
// http://localhost:9080/auth/realms/jhipster/.well-known/openid-configuration

{
  "issuer": "http://localhost:9080/auth/realms/jhipster",
  "authorization_endpoint": "http://localhost:9080/auth/realms/jhipster/protocol/openid-connect/auth",
  "token_endpoint": "http://localhost:9080/auth/realms/jhipster/protocol/openid-connect/token",
  "token_introspection_endpoint": "http://localhost:9080/auth/realms/jhipster/protocol/openid-connect/token/introspect",
  "userinfo_endpoint": "http://localhost:9080/auth/realms/jhipster/protocol/openid-connect/userinfo",
  "end_session_endpoint": "http://localhost:9080/auth/realms/jhipster/protocol/openid-connect/logout",
  "jwks_uri": "http://localhost:9080/auth/realms/jhipster/protocol/openid-connect/certs",
  "check_session_iframe": "http://localhost:9080/auth/realms/jhipster/protocol/openid-connect/login-status-iframe.html",
  "grant_types_supported": [
    "authorization_code",
    "implicit",
    "refresh_token",
    "password",
    "client_credentials"
  ],
  "response_types_supported": [
    "code",
    "none",
    "id_token",
    "token",
    "id_token token",
    "code id_token",
    "code token",
    "code id_token token"
  ],
  "subject_types_supported": [
    "public",
    "pairwise"
  ],
  "id_token_signing_alg_values_supported": [
    "RS256"
  ],
  "userinfo_signing_alg_values_supported": [
    "RS256"
  ],
  "request_object_signing_alg_values_supported": [
    "none",
    "RS256"
  ],
  "response_modes_supported": [
    "query",
    "fragment",
    "form_post"
  ],
  "registration_endpoint": "http://localhost:9080/auth/realms/jhipster/clients-registrations/openid-connect",
  "token_endpoint_auth_methods_supported": [
    "private_key_jwt",
    "client_secret_basic",
    "client_secret_post"
  ],
  "token_endpoint_auth_signing_alg_values_supported": [
    "RS256"
  ],
  "claims_supported": [
    "sub",
    "iss",
    "auth_time",
    "name",
    "given_name",
    "family_name",
    "preferred_username",
    "email"
  ],
  "claim_types_supported": [
    "normal"
  ],
  "claims_parameter_supported": false,
  "scopes_supported": [
    "openid",
    "offline_access"
  ],
  "request_parameter_supported": true,
  "request_uri_parameter_supported": true
}

The one from my Okta instance has the end_session_endpoint too. I tried configuring a redirect to it, but there's a CORS error and I can't seem to get around it.

I also tried using a RestTemplate, but can't seem to get the access token from Spring Security. Here's my attempt that doesn't work.

@SuppressWarnings("unchecked")
public class OidcLogoutSuccessHandler extends AbstractAuthenticationTargetUrlRequestHandler implements LogoutSuccessHandler {
    private RestTemplate restTemplate = new RestTemplate();

    public void onLogoutSuccess(HttpServletRequest request, HttpServletResponse response, Authentication authentication) throws IOException, ServletException {
        OAuth2Authentication auth = (OAuth2Authentication) authentication;
        System.out.println(auth.getUserAuthentication().getDetails());

        String accessToken = ((Map<String, Object>) auth.getUserAuthentication().getDetails()).get("access_token").toString();

        HttpHeaders headers = new HttpHeaders();
        headers.setContentType(MediaType.APPLICATION_JSON);
        headers.set("Authorization", "Bearer " + accessToken);

        HttpEntity<String> entity = new HttpEntity<>(headers);
        String result = restTemplate.postForObject("https://dev-158606.oktapreview.com/oauth2/default/v1/logout", entity, String.class);

        System.out.println(result);
    }
}

[jdubois]

Yes login out of the OIDC server is better, but that's a new feature - I'd first like to have the normal stuff working fine. I'm committing this soon, and I will link it here.

[jdubois]

And with this new code I have Swagger working on the gateway :-)

[StayHungryStayFoolish]

@mraible I can not find the logout() and logoutUrl("/api/logout") in the Monolithic application version 4.14.1. I want find the restful API when the current user log out .

[mraible]

@StayHungryStayFoolish Please do not comment on closed issues. If you have a question about JHipster, please post it to Stack Overflow with the "jhipster" tag. All the JHipster developers are subscribed and will get a notification when you do. If you've found a bug in JHipster, please submit a new issue with steps to reproduce. Even better, send a pull request to fix the issue you found! You can find out how to do this in our contributing guide.

[ome89]

I see that the issue is marked 'closed' but I am wondering if it is fixed.

[DanielFran]

@ome89 The PR #8757 fixes the issue and will be included in next V6 Jhipster release that is comming in next few days.

[ruddell]

This should be available in JHipster v5.8.0+