SAML против федеративного входа с OAuth
В чем разница между SAML и федеративным входом через OAuth? Какое решение имеет больше смысла, если компания хочет использовать стороннее веб-приложение, а также хочет иметь единый вход и быть центром аутентификации?
7 ответов
Они решают разные проблемы.
SAML - это набор стандартов, которые были определены для обмена информацией о том, кем является пользователь, каковы его наборы атрибутов, и дают вам возможность предоставить / запретить доступ к чему-либо или даже запросить аутентификацию.
OAuth больше о делегировании доступа к чему-либо. Вы в основном позволяете кому-то "действовать" как вы. Его чаще всего используют для предоставления доступа к API, которые могут сделать что-то от вашего имени.
Это две совершенно разные вещи.
Некоторые примеры, которые могут помочь.
О, подумай о твиттере. Допустим, вы используете Google Buzz и Twitter, и вы хотите написать приложение, чтобы синхронизировать их. Вы можете установить доверие между вашим приложением и твиттером. Когда вы впервые связываете приложение с твиттером, вы делаете классический запрос на вход в твиттер, а затем появляется окно подтверждения с вопросом "Хотите ли вы предоставить доступ к" имени вашего приложения "?" как только вы нажмете "да", доверие будет установлено, и теперь ваше приложение может действовать как вы в Twitter. Он может читать ваши сообщения, а также создавать новые.
SAML - для SAML подумайте о некоем "соглашении" между двумя несвязанными системами членства. В нашем случае мы можем использовать US Airways и Hertz. Не существует общего набора учетных данных, которые могли бы перенести вас с одного сайта на другой, но предположим, что Hertz хочет предложить "сделку" US Airways. (Конечно, я знаю, что это крайний пример, но потерпите меня). После покупки рейса они предложат бесплатный прокат автомобиля своим членам. US Airways и Hertz установили бы некоторую форму доверия и способ идентификации пользователя. В нашем случае нашим "федеративным идентификатором" будет адрес электронной почты, и это будет один из способов доверия, которым Герц доверяет, чтобы поставщик удостоверений US Airways предоставил токен, который является точным и безопасным способом. После бронирования рейса поставщик идентификационных данных US Airways сгенерирует токен и укажет способ аутентификации пользователя, а также "атрибуты" о человеке, в нашем случае наиболее важным атрибутом будет его уровень статуса в US Airways. После того, как токен заполнен, он передает его через какой-либо тип ссылки или кодируется в URL-адресе, и как только мы добираемся до Герца, он смотрит на токен, проверяет его и теперь может предоставить бесплатный прокатный автомобиль.
Проблема с этим примером SAML в том, что это только один специализированный вариант из многих. SAML является стандартом, и существует почти слишком много способов его реализовать.
В качестве альтернативы, если вы не заботитесь об авторизации, вы можете почти утверждать, что утверждение аутентификации через SAML и OpenID.
Взгляните на это простое объяснение, приведенное здесь:
Многие люди не понимают различий между SAML, OpenID и OAuth, но на самом деле все очень просто. Хотя есть некоторые совпадения, здесь есть очень простой способ различения трех.
OpenID - единый вход для потребителей
SAML - единый вход для корпоративных пользователей
OAuth - авторизация API между приложениями
Я думаю, что для тех, кто знаком с шаблонами дизайна ОО, есть хорошее следствие шаблонов обертки. Подумайте о моделях Фасад, Декоратор и Прокси. По сути, это все одно и то же, они просто обертки... Разница заключается в намерении каждого шаблона.
Точно так же SAML, OAuth и OpenID способствуют различным намерениям с помощью общего базового механизма, который заключается в перенаправлении к поставщику услуг / органу идентификации для некоторого частного взаимодействия с последующим перенаправлением в исходное стороннее приложение.
Оглядываясь в сети, вы обнаружите, что возможности протоколов перекрываются. Аутентификация через OAuth вполне разумна. SSO через OAuth может не иметь большого смысла, поскольку SAML и OpenID специально ориентированы на федеративную идентификацию.
К самому вопросу, в корпоративном контексте SAML звучит более подходящим, чем OAuth для SSO. Держу пари, если вы посмотрите на сторонние приложения, которые вы хотите интегрировать с вашими корпоративными удостоверениями, вы обнаружите, что они уже разработаны для интеграции с SAML/LDAP/Radius и т. Д. IMO OAuth больше подходит для интернет-взаимодействия между приложениями или, возможно, приложениями, составляющими сервис-ориентированную архитектуру, в большой корпоративной среде.
Правила авторизации могут быть указаны в корпоративной среде и другими способами. LDAP является распространенным инструментом для этого. Организация пользователей в группы и объединение привилегий приложений против членства в группах является широко распространенным подходом. Точно так же LDAP может использоваться и для аутентификации. Active Directory - отличный пример, хотя я предпочитаю OpenLDAP.
Найдена хорошая статья здесь
SAML (язык разметки безопасности) - это набор стандартов для обеспечения единого входа (SSO), федерации и управления идентификацией.
Пример: пользователь (основной участник) проходит проверку подлинности на веб-сайте бронирования авиабилетов, AirFlyer (поставщик удостоверений), для которого SSO настроен через SAML с веб-сайтом бронирования трансферов,Shuttler (поставщик услуг). После аутентификации на Flyer пользователь может заказать шаттлы на Shuttler без необходимости аутентификации
OAuth (Open Authorization) - это стандарт для авторизации ресурсов. Это не касается аутентификации.
Пример: мобильное приложение для обмена фотографиями (потребитель OAuth), которое позволяет пользователям импортировать фотографии из своей учетной записи Instagram (поставщик OAuth), которое отправляет временный токен или ключ к приложению для обмена фотографиями, срок действия которого истекает через несколько часов.
Они обрабатывают тонкий случай использования
- SAML - предоставление учетных данных (например, SSO) пользователя различным поставщикам услуг (например, веб-службе или веб-службе)
- OAuth - пользователь, делегирующий приложение для доступа к ресурсу от имени своего
SAML имеет множество "профилей", позволяющих другим пользователям "входить" на ваш сайт. SAML-P или SAML Passive очень распространены и довольно просты в настройке. WS-Trust аналогичен, и он также допускает федерацию среди веб-сайтов.
OAuth предназначен для авторизации. Вы можете прочитать больше здесь:
SAML предназначен для аутентификации - в основном используется в сценарии единого входа. OAuth для авторизации представлений ресурсов.
JSON Web Token (JWT) является альтернативой для SAML XML Tokens. JWT можно использовать с OAuth
Хорошая ссылка - SAML vs. OAuth: какую мне использовать?
Термины федерация действительно означают идентификаторы соединения между системами. Это связано с SSO, но они не совсем одинаковы. Я нашел этот пост в блоге действительно полезным с точки зрения того, что на самом деле означает федерация.