2010-08-24 11 views
7

Кажется, что Microsoft ADFSv2 поддерживает WS-Trust и SAML Passive, но стек WIF, на котором он построен, не поддерживает SAML.В чем разница между WS-Trust, OpenID и SAML Passive?

В чем разница между WS-Trust и SAML-P? Разделяют ли они одни и те же уязвимости безопасности, если да, то каковы они?

Примечание: Существует аналогичный, но другой вопрос здесь:

SAML vs OAuth

ответ

7

Я предполагаю, что вы имеете в виду [недавно выпущенном] ADFS v2?

Да, ADFS v2 поддерживает WS-Trust (и WS-Federation) и SAML2 пассивные, а WIF поддерживает только WS-Trust (и WS-Federation), а не SAML2 (ни пассивный, ни активный).

WS-Federation использует WS-Trust для выполнения пассивной федерации на основе браузера и во многом похож на пассивный SAML2 - и во многих отношениях это не так. Существенной разницей между WS-Federation и SAML2 пассивным является то, что WS-Federation v1.1 (новая версия, поддерживаемая ADFS v2) поддерживает автоматическое обнаружение метаданных. Вам нужно только указать конечную точку метаданных (URL-адрес) в WS-Federation, тогда как в SAML вам необходимо обменивать документы метаданных каким-то выбранным методом (usb stick, mail и т. Д.).

Я не знаю никаких реальных уязвимостей безопасности в любом протоколе, но подход к обмену метаданными можно обсуждать навсегда. Подход WS-Federation делает многое гораздо проще, например, переключение сертификатов, автоматическое обновление, «бесплатное» автоматическое предоставление новых членов в федерации и т. Д. Однако «ручная» процедура обмена в SAML2 может по крайней мере в теории быть более безопасным.

Что касается того, почему поддержка SAML не включена в WIF, я могу только догадываться. Приличное предположение может быть, что кто-то хочет сайты с помощью WIF в федеративном с ADFS, а не непосредственно с какой-либо другой [третьей стороной] IdP :-)

+0

Является ли базовое шифрование одинаковым между SAML/WS-Fed? Сравнивает ли SAML2 с WS-Fed лучше, чем SAML2 с WS-Trust? Что больше похоже на сравнение яблок с яблоками? – LamonteCristo

+0

Учитывая, что ADFS также поддерживает SAMLP, более вероятно, что команда WIF просто не успела добавить (и проверить) эту функцию. WIF имеет точки расширяемости для добавления других форматов протоколов/токенов. Даже у Microsoft нет бесконечных ресурсов :-) –

+0

@ makerofthings7 Пассивный профиль SAML2 можно сравнить с WS-Fed, поскольку активный SAML2 можно сравнить с WS-Trust (по крайней мере, на высоком уровне). Что касается шифрования, это зависит от конфигурации протокола. Вообще говоря, они поддерживают одни и те же алгоритмы, и, с практической точки зрения, платформа (.Net, Java и т. Д.) Обычно будет ограничивающим фактором, поскольку они часто не поддерживают все варианты, разрешенные спецификациями. Тем не менее, протоколы «требуют» шифрования как таковые, хотя шифрование является хорошей идеей в некоторых ситуациях (например, для доказательств или если конфиденциальность является проблемой). –

3

От The SSO Academy, очень простой разницы,

Многих людей смущены различиями между SAML, OpenID и OAuth, но на самом деле это очень просто. Хотя существует некоторое перекрытие , вот очень простой способ провести различие между тремя .

OpenID – single sign-on for consumers 
SAML – single sign-on for enterprise users 
OAuth – API authorization between applications 
3

Обновленный и исправленный ответ на 2015

  • OpenID-Connect (или РСИН) - новый единый вход по протоколу
    • Является ли OpenID версии 3, а не обратно совместимы ,
    • Построен на основе технологии OAuth
    • использует JWT (для маркеров, а также других веб-технологий JSON и определения)
  • WS-Federation (или WS-Fed) - старый единый вход в систему протокола
    • Использование SAML для своих маркеры

Определения:

  • JWT - определение JSON для маркеров безопасности (в OAuth и РСИН)
    • Произносится как слово "йота".
  • SAML - XML ​​схема и определение для маркеров безопасности (в WS-Fed)

OAuth

  • OAuth - это набор спецификаций для делегирования авторизация от запрашивающего приложения (клиента) к службе авторизации.
    • Уполномоченное использование даются в «объеме»
    • Объем состоит из набора безопасности «претензий» и необходимости «ресурсов»
    • Разрешенные объемы возвращаются в JWT Токен ресурса
    • Значки могут быть возвращены несколькими способами.Наиболее распространенными являются:
      • Маркер возвращен непосредственно: В неявное поток - используется для браузера на основе (JavaScript) приложений
      • маркеров, возвращаемых в два этапа, после получения «код доступа» - используется для сервера (REST или веб-API).
    • В некоторых случаях пользователь-пользователь демонстрирует пользовательский интерфейс, чтобы согласиться разрешить все или некоторые запрошенные «ресурсы».
    • Токены могут содержать актуальную информацию или быть ссылка на сервер, содержащий информацию.

РСИН (Open ID Connect)

  • запускается запрашивающее объем OATH с требованием типа OpenID-Connect
  • ОП - провайдера РСИН является сервером OAuth, соответствующим протоколу OIDC
  • Идентификатор идентичности не указан OP - поставщик OIDC.
    • маркеры идентификации содержат информацию (требования) о пользователе
    • В некоторых случаях человек пользователь будет показан пользовательский интерфейс, чтобы разрешить некоторые или все из запрашиваемой информации и ресурсов.

См Travis Spenscer's OAuth and OIDC article - его легко читать.

Если у вас нет изменений, пожалуйста, пометьте им как ответ. Благодарю.

 Смежные вопросы

  • Нет связанных вопросов^_^