Проблема допустимого использования политики с делегатской аутентификацией - PullRequest
Новая
       60

Проблема допустимого использования политики с делегатской аутентификацией

0 голосов
/ 21 февраля 2019

Мы настроили обе функции, указанные в названии, на основе официальных документов ( aup & делегатная аутентификация .

Мы используем аутентификацию с отладкой для интеграции с внешнимsaml провайдер idp. Таким образом, у нас есть два способа аутентификации: аутентификация idp и локальный (cas authenticator во внутренней базе данных).

После внешней и внутренней аутентификации нам нужно показать представление политики использования принятия, когда условие A

Вышеуказанное работает как предназначенное для локального входа в систему, однако , когда аутентификация выполняется во внешнем idp, страница политики допустимого использования не отображается , даже еслиусловие А выполнено, и пользователь в конечном итоге входит в систему в первоначально запрошенной службе.

Вопрос : Почему это происходит и существуют ли возможные обходные пути?

Версия сервера Cas: 5.3.7

1 Ответ

0 голосов
/ 22 февраля 2019

Если вы изучите этот блок , вы обнаружите, что проверка использования политики связана и создается как действие входа STATE_ID_CREATE_TICKET_GRANTING_TICKET: 

final ActionState ticketCreateState = getState(flow, CasWebflowConstants.STATE_ID_CREATE_TICKET_GRANTING_TICKET, ActionState.class);
ticketCreateState.getEntryActionList().add(createEvaluateAction("acceptableUsagePolicyVerifyAction"));
createTransitionForState(ticketCreateState, AcceptableUsagePolicyVerifyAction.EVENT_ID_MUST_ACCEPT, VIEW_ID_ACCEPTABLE_USAGE_POLICY_VIEW);

Этоограничение потока AUP таким образом, что результат действия проверки как бы игнорируется, и он не учитывает запуск окончательного представления, даже если оно указывает на это, в случае использования делегирования специально.

6.0.x ветвь немного меняет эту логику, чтобы улучшить это поведение: 

val ticketCreateState = getState(flow, CasWebflowConstants.STATE_ID_CREATE_TICKET_GRANTING_TICKET, ActionState.class);
createEvaluateActionForExistingActionState(flow, ticketCreateState.getId(), AUP_VERIFY_ACTION);
createTransitionForState(ticketCreateState, CasWebflowConstants.TRANSITION_ID_AUP_MUST_ACCEPT, VIEW_ID_ACCEPTABLE_USAGE_POLICY_VIEW);

Вы можете поэкспериментировать с тем же подходом в своем развертывании 5.3.x и доложить.Обязательно тщательно протестируйте оба случая.Если все работает как положено, отправьте сообщение обратно, а затем вы можете отправить запрос на извлечение проекта, чтобы изменить / исправить это поведение.

PS Обратите внимание, что запутывание различных действий и состояний веб-потока является чем-то очень сложным,поскольку есть много модулей, которые хотят вставить себя в правильное состояние веб-потока, чтобы приспособиться к некоторому поведению.Такие модули, как правило, ничего не знают друг о друге и пытаются несколько увеличить поток.В этих ситуациях объединение таких вещей в одно целое может быть довольно сложным делом.

...