Клиент JavaScript, получающий доступ к веб-сервису с федеративной аутентификацией — кросс-доменный

Я ищу небольшой совет по передовой практике от кого-то более осведомленного, чем я, в области федеративной безопасности.

Наш сценарий

Мы размещаем (подписной) веб-сервис (WCF/Asp.Net/IIS). У нас также есть компонент исключительно JavaScript (виджет), который наши клиенты встраивают в свои интранет-приложения. Виджет вызывает веб-сервисы для получения данных, поэтому нам нужен виджет для выполнения междоменных запросов из их домена в наш домен.

В настоящее время виджет делает это, используя комбинацию JsonP и подхода внедрения тегов скрипта к Ajax. (Причина — сочетание возраста виджета и продолжающейся поддержки старых браузеров без CORS).

Проблема

Всем нашим клиентам требуется единый вход, чтобы их пользователей не просили войти в виджет. До сих пор мы добивались этого, выдавая ApiKey новому пользователю и прося его ввести его в виджет при первом использовании, а затем создавался файл cookie для последующего использования.

Нам нужно интегрировать Federated Authentication в этот сценарий. Веб-служба (в нашем домене) — это проверяющая сторона (RP), а виджет (размещенный в домене клиента) — это клиент. Поставщик удостоверений и STS также будут находиться в домене клиента.

Из моего исследования на данный момент я думаю, что могу сделать следующие заявления:

  • Этот сценарий требует подхода Active Federation. Пассивная федерация никогда не используется, если RP является веб-службой.
  • Нам нужно добавить федеративные конечные точки в нашу службу WCF, чтобы активный клиент мог вызывать нас, предоставляя токен Saml.
  • Сделать наш виджет активным клиентом, напрямую взаимодействующим с веб-службой, невозможно. Это потребует от виджета запроса удостоверения и передачи его на RP. Это было бы слишком много для приложения только для JavaScript.

Возможные решения

  1. Действительно ли хост-страница виджета (также известная как приложение интрасети клиента) должна быть клиентом в сценарии FedAuth?
  2. Мы могли бы предоставить прокси-сервер, который будет размещаться в домене клиента и действовать как активный клиент для наших RP веб-сервисов. Тогда виджет может не знать о какой-либо аутентификации.
  3. Мы упускаем что-то действительно очевидное?

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


person Andy McCluggage    schedule 24.06.2013    source источник


Ответы (1)


В конце концов мы нашли обходной путь:

Для клиентов, которым нужна аутентификация Saml, мы размещаем компонент виджета в нашем домене на отдельной веб-странице, и они встраивают его в свою веб-страницу с помощью iframe.

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

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

person Andy McCluggage    schedule 20.08.2013