SAML против федеративного входа с OAuth
в чем разница между SAML и федеративным логином с OAuth? Какое решение имеет больше смысла, если компания хочет использовать стороннее веб-приложение, и а также хочет единого входа и проверки подлинности?
7 ответов
Они решают разные задачи.
на основе SAML - это набор стандартов, которые были определены для обмена информацией о том, кто пользователь, что его набор атрибутов, и дать вам способ предоставить/запретить доступ к чему-то или даже запросить аутентификацию.
OAuth больше о делегировании доступа к чему-то. Вы в основном позволяете кому-то" действовать " как вы. Наиболее часто используется для предоставления доступа api, которые могут что-то сделать от вашего имени.
Это две совершенно разные вещи.
некоторые примеры, которые могут помочь.
OAuth подумайте о Твиттере. Допустим, вы используете Google Buzz и Twitter, и вы хотите написать приложение, чтобы иметь возможность держать два синхронизированы. Вы в основном можете установить доверие между вашим приложением и twitter. Первый раз, когда вы идете, чтобы связать приложение с twitter, Вы делаете классическое приглашение войти в twitter, а затем появляется окно подтверждения и спрашивает: "Вы хотите предоставить доступ к "вашему имени приложения"?"как только вы нажмете "да", доверие будет установлено, и теперь ваше приложение может действовать как вы в Twitter. Он может читать ваши сообщения, а также создавать новые.
SAML-для SAML подумайте о некотором типе "соглашения" между двумя несвязанными системами членства. В нашем случае мы можем использовать US Airways и Hertz. Нет общего набора учетных данных, который может переносить вас с одного сайта на другой, но предположим, что Hertz хочет предложить" сделку " US Airways. (Конечно, я знаю, что это крайний пример, но потерпите меня). После покупки рейса, они предложат бесплатный прокат авто своим членам-председателям. US Airways и Hertz установят некоторую форму доверия и какой-то способ идентификации пользователя. В нашем случае нашим "федеративным id" будет адрес электронной почты, и это будет один из способов набора доверия Hertz доверяет, что US Airways identity provider доставит токен, который является точным и безопасным способом. После бронирования рейса US Airways identity provider будет генерировать токен и заполнять, как они аутентифицировали пользователя, а также" атрибуты " о человеке в нашем случае самым важным атрибутом будет его уровень статуса в US Airways. Как только токен был заполнен, он передает его через какой-то тип ссылки или закодирован в url-адресе, и как только мы доберемся до Hertz, он смотрит на токен, проверяет его и теперь может разрешить бесплатный прокат автомобилей.
проблема с этим SAML пример-это только один специализированный вариант использования из многих. SAML является стандартом, и существует слишком много способов его реализации.
альтернативно, если вы не заботитесь об авторизации, вы можете почти утверждать, что утверждение аутентификации через SAML и OpenID.
посмотреть Это простое объяснение подведены здесь:
многие люди путают о различиях между SAML, OpenID и OAuth, но на самом деле это очень просто. Хотя есть некоторые перекрытие, здесь очень простой способ различать между три.
OpenID-единый вход для потребителей
SAML-единый вход для корпоративных пользователей
авторизация OAuth – API между приложения
для людей, удобных с шаблонами дизайна OO, я думаю, что есть хорошее следствие шаблоны обертки. Подумайте о фасад, оформителя и Прокси шаблоны. По сути, это все одно и то же, это просто обертки... разница намерение каждого шаблона.
аналогично, SAML, OAuth и OpenID все облегчают различные намерения через общий основной механизм, которое перенаправление к поставщику услуг / органу идентификации для некоторого частного взаимодействия, а затем перенаправление на исходное приложение третьей стороны.
глядя вокруг в сети, вы найдете перекрытие между возможностями протоколов. аутентификация через OAuth - это вполне разумно. SSO над OAuth может не иметь большого смысла, хотя, как SAML и OpenID специально ориентирована на федеративную идентичность.
к самому вопросу,в корпоративном контексте SAML звучит более уместно, чем OAuth для SSO. Держу пари, если вы посмотрите на сторонние приложения, которые вы хотите интегрировать с вашими корпоративными идентификаторами, вы обнаружите, что они уже разработаны для интеграции с SAML/LDAP/Radius и т. д. IMO OAuth более подходит для интернет-взаимодействия между приложениями или, возможно, приложениями, содержащими сервис-ориентированную архитектуру в большой корпоративной среде.
правила авторизации могут быть указаны в корпоративной среде и другими способами. LDAP является общим инструментом для этого. Широко распространенным подходом является организация пользователей в группы и связывание привилегий приложений с членством в группах. Просто так получилось, что LDAP можно использовать и для аутентификации. Active Directory-отличный пример, хотя я предпочитаю OpenLDAP.
SAML имеет множество " профилей "на выбор, чтобы позволить другим пользователям" войти " на ваш сайт. SAML-P или SAML Passive очень распространены и довольно просты в настройке. WS-Trust аналогичен, и он также позволяет Федерацию между веб-сайтами.
OAuth предназначен для авторизации. Вы можете прочитать больше здесь:
они обрабатывают тонкий случай использования
- SAML-общие учетные данные (например, SSO) пользователя для различных поставщиков услуг (например, веб-или веб-службы)
- OAuth - пользователь, делегирующий приложение для доступа к ресурсу от имени своего
SAML для аутентификации-в основном используется в Единый Вход сценарий. OAuth предназначен для авторизации представлений ресурсов.
JSON Web Token (JWT) является альтернативой для токенов SAML XML. JWT может использоваться с OAuth
хорошая ссылка SAML против OAuth: какой из них я должен использовать?
термины Федерация действительно означает идентификаторы соединений между системами. Это связано с SSO, но они не совсем то же самое. Я нашел это сообщение в блоге очень полезным с точки зрения того, что на самом деле означает Федерация.
нашел хорошую статью здесь
SAML (Security Assertion Markup Language) - это набор стандартов для достижения единого входа (SSO), Федерации и управления идентификацией.
пример : пользователь (Принципал) аутентифицируется на веб-сайте бронирования авиабилетов, авиалайнер (поставщик удостоверений личности), который имеет SSO, настроенный через SAML с веб-сайтом бронирования шаттлов, Shuttler (поставщик услуг). После аутентификации Флаер, пользователь может заказать шаттлы на шаттле, не требуя аутентификации
OAuth (Открытая авторизация) является стандартом для авторизации ресурсов. Он не имеет дело с аутентификацией.
пример: мобильное приложение для обмена фотографиями (OAuth consumer), которое позволяет пользователям импортировать фотографии из своей учетной записи Instagram (OAuth provider), которая отправляет временный маркер доступа или ключ к приложению для обмена фотографиями, срок действия которого истекает через несколько часов.