Keycloak застрял в петле после входа в систему - PullRequest
Новая
       37

Keycloak застрял в петле после входа в систему

0 голосов
/ 19 сентября 2019

Я настроил Keycloak как IdP для единого входа с использованием SAML2.0.Я зарегистрировал своего клиента на Keycloak с необходимыми URL-адресами: Основной URL-адрес для обработки SAML: <a href="http://localhost:8085/myapp/saml" rel="nofollow noreferrer">http://localhost:8085/myapp/saml</a> Хотя нет необходимости, когда у меня установлен главный URL-адрес: у меня ACS URL POST Binding, Logout URL POST Binding оба установлены на: <a href="http://localhost:8085/myapp/saml" rel="nofollow noreferrer">http://localhost:8085/myapp/saml</a>Root URL: <a href="http://localhost:8085/myapp" rel="nofollow noreferrer">http://localhost:8085/myapp</a>

Когда я пытаюсь получить доступ к защищенному ресурсу, т. Е. URL-адрес вида <a href="http://localhost:8085/myapp/protected/" rel="nofollow noreferrer">http://localhost:8085/myapp/protected/</a>*, Keycloak перенаправляет меня на свою страницу входа.Теперь, когда после успешного входа в систему я получаю доступ к URL-адресу ACS, я пытаюсь перенаправить страницу на один из защищенных ресурсов.Делаем это: resp.sendRedirect("<a href="http://localhost:8085/myapp/protected/home.html" rel="nofollow noreferrer">http://localhost:8085/myapp/protected/home.html</a>");.

Теперь Keycloak снова перенаправляет меня на страницу входа, а затем застревает в бесконечном цикле.

Моя web.xml конфигурация: 

  <filter>
    <filter-name>Keycloak Filter</filter-name>
    <filter-class>org.keycloak.adapters.saml.servlet.SamlFilter</filter-class>
  </filter>
  <filter-mapping>
    <filter-name>Keycloak Filter</filter-name>
    <url-pattern>/protected/*</url-pattern>
  </filter-mapping>

-Некоторые люди решили эту проблему, завершив главный URL-адрес /saml, который у меня уже есть.-Я также пытался поставить /rest в конце URL-адреса ACS, но ничего не работает

Он просто показывает Your are already logged in или просто продолжает перенаправлять

1 Ответ

0 голосов
/ 29 сентября 2019

Я просмотрел журналы Keycloak, чтобы найти Info: Assertion expired.В моем случае Keycloak и Service Provider (клиент) находятся на разных машинах.Ошибочное различие было в том, что их системное время было в другом часовом поясе.

SP создавал SAMLRequest в UTC в соответствии со своим часовым поясом, а SAMLResponse приходил в UTC в соответствии с другим часовым поясом.

Таким образом, поддержание того же часового пояса решило проблему.

...