Keycloak Backchannel выход из системы - PullRequest
Новая
       22

Keycloak Backchannel выход из системы

0 голосов
/ 02 мая 2018

Я пытался понять поток выхода из обратного канала из моего веб-приложения, но я нахожу документацию запутанной. У меня есть приложение JEE, работающее в JBoss EAP, с адаптером сервлетов Java (по некоторым техническим причинам я не могу использовать адаптер EAP). документация для выхода гласит:

Вы можете выйти из веб-приложения несколькими способами. Для Java EE Контейнеры сервлетов вы можете вызвать HttpServletRequest.logout (). За другие приложения браузера, вы можете перенаправить браузер на http://auth -server / auth / realms / {realm-name} / protocol / openid-connect / logout? Redirect_uri = encodedRedirectUri, который выходит из системы, если у вас есть сеанс SSO с вашим браузером.

Документация для Конфигурация URL администратора гласит:

Например, как работает выход из обратного канала: 1. Пользователь отправляет запрос на выход из одного приложения 2. Приложение отправляет запрос на выход из системы Keycloak 3. Сервер Keycloak делает недействительным сеанс пользователя 4. Затем сервер Keycloak отправляет запрос обратного канала приложению с URL-адресом администратора, связанным с сеансом. 5. Когда приложение получает запрос на выход из системы, оно делает недействительным соответствующий HTTP-сеанс

Итак, насколько я понимаю, либо:

  1. вызов HttpServletRequest.logout () должен отправить запрос к Keycloak
  2. GET для http://auth-server/auth/realms/{realm-name}/protocol/openid-connect/logout?redirect_uri=encodedRedirectUri должен каким-то образом определять clientId (из URI перенаправления?) И отправлять запрос в соответствующий обратный канал

Кажется, ни один из вариантов не работает для меня. Ни в том, ни в другом случае я не получаю обратный вызов от Keycloak к моему adminUrl. Кроме того, я все еще вижу такое же количество активных сеансов в администраторе Keycloak после вызова Request.logout (). Согласно этому SO сообщению , это похоже на работу, но я не уверен, что мне не хватает конфигурации или чего-то в этом роде.

Я пытался отправить GET конечной точке выхода с помощью access_token, но это тоже не имеет значения.

Что я неправильно понимаю из этой документации? Как мне кодировать выход из системы?

1 Ответ

0 голосов
/ 01 июня 2018

Обычный выход из системы и выход из обратного канала - это две разные вещи.

Обычный выход из системы работает , перенаправляя браузер на URL, который вы упомянули в (2). Пользователь распознается сеансом браузера в Keycloak, поэтому перенаправление браузера имеет решающее значение (redirect_uri даже не требуется предоставлять).

Мы достигли этого в Tomcat, вызвав следующий код в нашем приложении, который сам запускает перенаправление (используя, конечно, keycloak.json): 

Object keycloakAttr = request.getAttribute(KeycloakSecurityContext.class.getName());
if (keycloakAttr != null && keycloakAttr instanceof RefreshableKeycloakSecurityContext) 
{
  // code inspired by org.keycloak.adapters.tomcat.AbstractKeycloakAuthenticatorValve.logoutInternal
  RefreshableKeycloakSecurityContext ksc = (RefreshableKeycloakSecurityContext)keycloakAttr;
  KeycloakDeployment deployment = ksc.getDeployment();
  ksc.logout(deployment);

  // Since a CatalinaSessionTokenStore is used as token store in Tomcat
  // tokenStore.logout() is not be necessary (???)

  request.removeAttribute(KeycloakSecurityContext.class.getName());
  request.setUserPrincipal(null);
}

A выход из обратного канала имеет смысл только в том случае, если несколько проверяющих сторон (на языке OIDC) или "клиенты" с точки зрения Keycloak в игре. Это гарантирует, что никакие клиентские сеансы клиентов в одной и той же области (для одного и того же пользователя) не «выживут» при выходе из системы.

После выполнения вышеприведенного выхода Keycloak проверяет, есть ли клиентские сеансы, связанные с сеансом Keycloak, и отправляет запросы на выход из обратного канала соответствующим клиентам (в той же области!), Следовательно, сеанс браузера вообще не участвует в этом процессе. .

Чтобы это работало (как для Node.js, так и для Tomcat с правильно установленным соответствующим адаптером Keycloak) нам было необходимо только правильно настроить URL-адрес администратора клиентов в Keycloak. Примечание. По умолчанию используется значение "/", но для Tomcat должен быть включен контекст веб-приложения, например https://myapp.com/mywebapp/

...