Могу ли я / как я могу использовать аутентификацию / единый вход для разных CAS-сервисов? - PullRequest
Новая
       20

Могу ли я / как я могу использовать аутентификацию / единый вход для разных CAS-сервисов?

0 голосов
/ 15 мая 2019

У меня зарегистрировано 2 службы CAS (CAS 6.0.3) (через JSON) с различными идентификаторами служб и AuthenticationHandlers и т. Д.Я могу снова аутентифицировать каждый из двух сервисов отдельно (например, cas / login? Service = http ... service1).Но когда я пытаюсь получить доступ ко второму Сервису (cas / login? Service = http ... service2) после того, как я уже аутентифицировал другой сервис, я получаю это сообщение об ошибке:

Ticket ... делаетне соответствует поставляемому сервису.Первоначальный сервис был ..., а поставляемый сервис был ...

Информация: все "..." совпадают / совпадают с Service-ID-String.Внутренний код сообщения об ошибке: «INVALID_SERVICE»

CAS считает, что «все в порядке, вы уже вошли в систему, и я могу перенаправить вас непосредственно к вашим услугам».Он даже делает SessionToken для проверки, а затем перенаправляет.Но когда вторая служба проверяет билет, появляется сообщение об ошибке.

Существует ли возможность разрешить Service1 и Service2 использовать один и тот же «контекст SSO» / CAS-Session / разрешить вход в систему service2 после входа в систему вService1?Может быть, есть RegisteredServiceProperty для этой темы, который я могу использовать в своей конфигурации службы-JSON?

Я уже прочитал все на этой странице: https://apereo.github.io/cas/6.0.x/index.html и даже пытался найти в исходном коде такиепараметры проверки ..

Это последние строки в моем журнале с включенным "trace" -Level: 

=============================================================
WHO: myuser
WHAT: ST-2-tNnqqJfwFeSSAqaQf-LBTF7AvsMLAPTOP-3DHMD58D
ACTION: SERVICE_TICKET_VALIDATE_SUCCESS
APPLICATION: CAS
WHEN: Wed May 15 11:02:14 CEST 2019
CLIENT IP ADDRESS: 127.0.0.1
SERVER IP ADDRESS: 127.0.0.1
=============================================================


2019-05-15 11:02:14,965 TRACE [org.apereo.cas.validation.AbstractCasProtocolValidationSpecification] - <Is validation specification set to enforce [renew] protocol behavior? [no]. Is assertion issued from a new login? [no]>
2019-05-15 11:02:14,965 TRACE [org.apereo.cas.validation.Cas20WithoutProxyingValidationSpecification] - <Number of chained authentications in the assertion [1]>
2019-05-15 11:02:14,965 TRACE [org.apereo.cas.validation.AbstractCasProtocolValidationSpecification] - <Validation specification is satisfied by the produced assertion>
2019-05-15 11:02:14,965 TRACE [org.apereo.cas.services.AbstractServicesManager] - <No environments are assigned to service [myservice]>
2019-05-15 11:02:14,965 DEBUG [org.apereo.cas.validation.RegisteredServiceRequiredHandlersServiceTicketValidationAuthorizer] - <Evaluating service [AbstractWebApplicationService(id=https://blub.blub, originalUrl=https://blub.blub, artifactId=ST-2-tNnqqJfwFeSSAqaQf-LBTF7AvsMLAPTOP-3DHMD58D, principal=null, source=service, loggedOutAlready=false, format=XML, attributes={})] to ensure required authentication handlers can satisfy assertion>
2019-05-15 11:02:14,965 TRACE [org.apereo.cas.util.CollectionUtils] - <Converting multi-valued element [[MailboxAuthenticationHandler]]>
2019-05-15 11:02:14,966 TRACE [org.apereo.cas.web.view.CasReloadableMessageBundle] - <Examining language bundle [classpath:custom_messages_de] for the code [INVALID_SERVICE]>
2019-05-15 11:02:14,966 TRACE [org.apereo.cas.web.view.CasReloadableMessageBundle] - <Examining language bundle [classpath:messages_de] for the code [INVALID_SERVICE]>

Ответ проверки: (сообщение об ошибке на немецком языке, ноэто тот же самый / INVALID_SERVICE-ошибка): 

<cas:serviceResponse xmlns:cas='http://www.yale.edu/tp/cas'>
    <cas:authenticationFailure code="INVALID_SERVICE">Ticket &#39;ST-2-tNnqqJfwFeSSAqaQf-LBTF7AvsMLAPTOP-3DHMD58D&#39; passt nicht zum angegebenen Service. Der urspr&amp;uuml;ngliche Service war &#39;https://blub.blub&#39; und der &amp;uuml;bermittelte Service war &#39;https://blub.blub&#39;.</cas:authenticationFailure>
</cas:serviceResponse>

1 Ответ

0 голосов
/ 15 мая 2019

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

Было бы неплохо, если бы «CAS» показывал более точное сообщение об ошибке (в журнале) в этом случае или если это было бы где-то задокументировано.

...