Shibboleth для нескольких сайтов на IIS - PullRequest
1 голос
/ 25 октября 2019

Я пытаюсь настроить поставщика услуг Shibboleth для двух сайтов на одном экземпляре IIS:

  • Интерфейс со статическим HTML - просто SPA - например, site.com
  • Backend сAPI - просто REST - например, site-api.com

Итак, когда я открываю первую точку входа, у меня есть 302 ответ с перенаправлением на IdP, после ввода учетных данных - перенаправление на сайт. com / Shibboleth.sso / SAML2 / POST и все работает нормально.

Мой SPA работает в браузере и выполняет AJAX-запрос к site-api.com. И вот проблема, потому что у меня есть 302 ответ с перенаправлением на IdP снова. В случае, если браузер делает запрос, у меня нет никаких проблем, потому что перенаправление на обработку браузера IdP автоматически. И снова после проверки подлинности с помощью файла cookie сеанса на IdP он перенаправляется на site-api.com/Shibboleth.sso/SAML2/POST.

Как я могу разделить сеанс между двумя сайтами? Можно ли не иметь перенаправление после первого запроса к site-api.com в случае, если пользователь уже прошел аутентификацию на site.com.

Я использовал для второго сайта:

        <ApplicationOverride id="site-api" entityID="https://site-api.com/shibboleth" />

Кроме того, я зарегистрировал ISAPI и RequestMap для site-api.com. Технически это работает так же, как и для site.com.

Я думаю, что могу как-то поделиться сессией, используя атрибут в XML-файле конфигурации, но у меня ничего не работает. Пожалуйста помоги. :)

1 Ответ

0 голосов
/ 26 октября 2019

Использование ApplicationOverride в Shibboleth SP вызывает вторичное приложение в качестве отдельной службы, т.е. вы установили, что этот entityID уникален. В случае вторичного API я бы не стал защищать его с помощью Shibboleth, то есть зачем защищать его с помощью Shibboleth SP (который создан для обеспечения аутентификации на основе IdP), если вы делаете вызовы RESTful с сайта, который уже аутентифицирован,Я думаю, вам нужно переосмыслить рабочий процесс аутентификации ... более разумная идея:

(1) Получить сеанс для site.com из IdP с использованием SAML / Shibboleth,

(2) Создайте сеанс приложения на основе сеанса SP (просмотрите сеансы в потоке SAML, на самом деле их несколько, а не только сеанс SP). Не говоря уже о том, что Shibboleth создан для Аутентификации, а не Авторизации.

(3) Выполните вызов API REST на основе любого механизма безопасности API, который вы хотите ... т.е. вы можете построить JWT на основе данных утверждения SAMLи убедитесь, что он действителен в конечной точке API, потому что вы знаете сертификаты.

Веб-поток SAML на самом деле не создан для API, как вы пытаетесь использовать его здесь ... 302, который вы пытаетесьчтобы избавиться от этого, это должно быть в рабочем процессе SAML.

...