CAS 6.1 - Нулевой параметр состояния с Pac4J - PullRequest
Новая
       123

CAS 6.1 - Нулевой параметр состояния с Pac4J

0 голосов
/ 09 января 2020

Я установил CAS с LDAP / AD и базой данных, которая работает. Теперь я хочу добавить Keycloak, но я получаю исключение, касающееся состояния. 

Caused by: org.pac4j.core.exception.TechnicalException: State parameter is different from the one sent in authentication request. Session expired or possible threat of cross-site request forgery

Для тестирования я добавил Google, но возникает похожая проблема. 

DEBUG [org.pac4j.oauth.credentials.extractor.OAuth20CredentialsExtractor] - <sessionState: null / stateParameter: Optional[TST-1-v1va-S-4rLb45kax1568WxwP5aX-q2X]>
INFO [org.pac4j.oauth.client.Google2Client] - <Failed to retrieve or validate credentials: State parameter mismatch: session expired or possible threat of cross-site request forgery>

Я вижу успешную авторизацию с токеном для keyloak / google в логах, что означает keycloak / гугл работа в принципе. Проблема заключается в том, что после перенаправления обратно в CAS сеанс уже завершился. Магазин сессий внутри контекста пуст. Следовательно, состояние равно нулю и не может быть сопоставлено с TST. Когда я устанавливаю withState = false в pac4j, все работает, но я хочу использовать состояние для безопасности.

В этом вопросе в группе pac4j google у кого-то возникла та же проблема, потому что он не не использовать стандартный порт, который я тоже сделал. Но переход на 80/443 не решил это для меня. Я работаю в Tomcat 9 с подписанным ssl-сертификатом на localhost.

Любые другие предложения?

Edit
Я почти уверен, что проблема связана с внешний кот. Но до сих пор я не нашел рабочей документации о том, как правильно настроить внешний tomcat. Открыто для предложений.

Обновление
Швы, подобные cas-server-support-oauth-webflow, нарушают веб-поток pac4j. Если я удаляю эту зависимость, это работает. Не знаю, если это ошибка или должна работать таким образом. Без OAuth-Webflow я не получаю access_token для Ldap / database.

1 Ответ

1 голос
/ 03 февраля 2020

У меня была такая же проблема, и мне удалось справиться с v6.2.0-RC2 версией cas. После добавления 

cas.authn.pac4j.replicateSessions=false

в мой etc/cas/config/cas.properties это исправило проблему для меня.

С https://github.com/apereo/cas/blob/v6.2.0-RC2/docs/cas-server-documentation/configuration/Configuration-Properties.md#pac4j -delegated-authn : 

# cas.authn.pac4j.typedIdUsed=false
# cas.authn.pac4j.principalAttributeId=
# cas.authn.pac4j.name=
# cas.authn.pac4j.order=
# cas.authn.pac4j.lazyInit=true
# cas.authn.pac4j.replicateSessions=true

С https://github.com/apereo/cas/blob/v6.2.0-RC2/api/cas-server-core-api-configuration-model/src/main/java/org/apereo/cas/configuration/model/support/pac4j/Pac4jDelegatedAuthenticationProperties.java#L58: 

 /**
 * Indicates whether profiles and other session data,
 * collected as part of pac4j flows and requests
 * that are kept by the container session, should be replicated
 * across the cluster using CAS and its own ticket registry.
 * Without this option, profile data and other related
 * pieces of information should be manually replicated
 * via means and libraries outside of CAS.
 */
 private boolean replicateSessions = true;

Предупреждение - Значение по умолчанию для этого свойства true и изменение на false не рекомендуется для кластеров.

...