CAS против SAML против OAuth2

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

Мои потребности кажутся достаточно простыми. В моей компании у нас есть куча приложений Ruby on Rails. Я хочу создать службу аутентификации SSO, которую должны использовать все эти приложения.

Попытка провести некоторое исследование о том, как это сделать, я читал о CAS, SAML и OAuth2. (Я знаю, что "Auth" в OAuth означает авторизацию, а не аутентификацию, но я достаточно читал статьи, говоря, что OAuth можно использовать для аутентификации просто отлично - this является одним из них.)

Может кто-нибудь сказать мне простыми словами, что это за 3? Являются ли они альтернативными (конкурирующими)? Правильно ли сравнивать их?

И есть так много драгоценных камней, которые, кажется, говорят очень похожие вещи:

https://github.com/rubycas/rubycas-server и https://github.com/rubycas/rubycas-client li >
https://github.com/nbudin/devise_cas_authenticatable
https://github.com/onelogin/ruby-saml
CASino и https://github.com/rbCAS/casino-activerecord_authenticator
И я уверен, что есть сотни драгоценных камней, связанных с OAuth.

Я просто хочу отдельное приложение Rails, которое обрабатывает всю аутентификацию для других приложений Rails.

Примечание.. Я не хочу, чтобы пользователи могли использовать свои учетные записи Google/Facebook для входа в систему. У наших пользователей уже есть учетные записи на нашем сайте. Я хочу, чтобы они могли войти в систему с помощью этой учетной записи и получить доступ ко всем нашим приложениям без повторного входа в систему. Выйти из любого приложения должно выписывать их из всех приложений.

UPDATE

Я столкнулся с этими двумя решениями OAuth:

Кажется, они описывают что-то очень похожее на то, что я хочу. Но я не нашел ни одного руководства/публикации в блоге/учебника, показывающего, как это сделать с помощью SAML/CAS.

Предложения приветствуются.

ОБНОВЛЕНИЕ 2

Подробнее о нашем прецеденте.

У нас нет существующей архитектуры SAML. Прежде всего, это будут НАШИ пользователи (зарегистрированные непосредственно на нашем сайте), которые будут получать доступ ко всем нашим приложениям. В будущем у нас могут быть сторонние (партнерские) компании, называющие наши API. У нас также могут быть пользователи из этих сторонних (партнерских) компаний (зарегистрированных на своих сайтах), обращаясь к нашим приложениям.

Ответ 1

Если вам необходимо пройти аутентификацию для LDAP или ActiveDirectory, то решение, подобное одному из CAS, которое вы упомянули выше, подходит вам ( RubyCAS, CASino).

Если вы можете себе это позволить, один из коммерческих поставщиков (например, Oktastrong > ) - ваш лучший вариант, потому что они останутся на вершине патчи безопасности и управлять вашими требованиями к аутентификации. В частности, если вы должны поддерживать ActiveDirectory, они уже внедрили его.

OAuth наиболее полезен для сторонней аутентификации, хотя он может выполнять SSO. Поэтому, если вы хотите поддерживать логины Google/Facebook или быть сторонним аутентификатором, тогда это отличный выбор. Поскольку вы не хотите поддерживать Google/Facebook, тогда OAuth, вероятно, не то, что вы хотите.

Если вы намерены использовать HTTP POST для своих потребностей в SSO, тогда можно было бы использовать драгоценный камень ruby-saml. Вам нужно будет реализовать собственный поставщик удостоверений и добавить компонент поставщика услуг на все ваши веб-сайты (возможно, в форме драгоценного камня). Часть того, что вам понадобится, - это rails api, чтобы выступать в качестве поставщика удостоверений. Этот gem помогает поддерживать API-интерфейс в рельсах.

ИЗМЕНИТЬ

Вы указываете, что будущие сторонние пользователи могут войти на ваш сайт. Это изменяет ваше исчисление в сторону от развертывания собственного решения ruby-saml.

Лучший способ поделиться своим API аутентификации - реализовать слой OAuth. Doorkeeper является популярным решением и быстро становится стандартом для аутентификации Rails. Это поддержка сообщества, гибкость и простота использования делают его лучшим способом для использования API-интерфейсов для пользовательской аутентификации.

Railscast для выполнения привратника

Ответ 2

CAS-сервера:

Автономная центральная страница входа, где пользователь вводит свои учетные данные (то есть их имя пользователя и пароль).

CAS поддерживает стандартизованный протокол SAML 1.1 в основном для поддержки отмена атрибута клиентам и однократное выключение.

(таблица в базе данных SQL, ActiveDirectory/LDAP, учетные записи Google и т.д.) Полная совместимость с открытым, многоплатформенным CAS-протоколом (клиенты CAS реализованы для широкого спектра платформ, включая PHP, различные фреймворки Java,.NET, Zope и т.д.). Локализация нескольких языков - RubyCAS-сервер автоматически определяет предпочтительный язык пользователя и представляет соответствующий интерфейс.

SAML: Язык разметки безопасности - это формат данных открытого стандарта на основе XML для обмена данными аутентификации и авторизации между сторонами, в частности, между поставщиком удостоверений и поставщиком услуг. SAML-авторизация - это двухэтапный процесс, и вы должны реализовать поддержку для обоих.

OAuth 2.0:

Структура авторизации OAuth 2.0 позволяет стороннему приложения, чтобы получить ограниченный доступ к службе HTTP, либо на от имени владельца ресурса путем организации взаимодействия с одобрением между владельцем ресурса и службой HTTP, или разрешив стороннего приложения для получения доступа от своего имени.

Важное примечание:

SAML имеет одну функцию, в которой OAuth2 не хватает: токен SAML содержит информацию о пользовательских идентификационных данных (из-за подписания). С OAuth2 вы не получите это из коробки, и вместо этого сервер ресурсов должен сделать дополнительную поездку туда и обратно, чтобы проверить токен с помощью сервера авторизации.

С другой стороны, с OAuth2 вы можете сделать недействительным токен доступа на сервере авторизации и отключить его от дальнейшего доступа к серверу ресурсов.

Оба подхода имеют приятные функции, и оба они будут работать для SSO. Мы доказали обе концепции на нескольких языках и в различных видах приложений. В конце дня OAuth2, по-видимому, лучше подходит для наших нужд (поскольку для использования не существует существующей инфраструктуры SAML).

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

Когда следует использовать какой?

1.Если ваш usecase включает SSO (когда хотя бы один актер или участник является предприятием), используйте SAML.

2.Если ваш usecase предполагает предоставление доступа (временно или постоянно) к ресурсам (например, учетные записи, изображения, файлы и т.д.), используйте OAuth.

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

4.Если ваш usecase требует централизованного источника идентификации, используйте SAML (поставщик удостоверений).

5. Если ваш usecase включает мобильные устройства, то OAuth2 с определенной формой токенов-носителей подходит.

Ссылка 1, Ссылка 2, Ссылка 3

Ответ 3

Anjan.

Я использовал CAS и OAuth в своей работе. Вот некоторые из моих мнений и надеюсь помочь.

В принципе

Оба CAS и SAML стремятся решить ситуацию с SSO. CAS - это служба или система аутентификации, которая может поддерживать протокол SAML.
OAuth стремится разрешить авторизацию и аутентификацию.

И на практике

Оба CAS и SAML действуют как шлюз перед группой приложений, принадлежащих одной организации. Также как ваш случай.
OAuth используется для авторизации и аутентификации между различными организациями.

Просто мои мысли и надеюсь услышать больше голосов.

Ответ 4

Поскольку у вас много ответов на этот вопрос, я хотел бы предложить вам продукт идентификации, который может обслуживать весь этот протокол в одной руке с множеством функций проверки подлинности и управления пользователями. Вы можете просто попробовать версию WSO2 Identity Server для этого.

Ответ 5

Мы использовали CAS и SAML в нашей архитектуре (Mobile App, Online Portal и MicroServices), и оба используются для разных целей. Наш онлайн-портал похож на онлайн-банкинг, который работает в общественном достоянии и должен быть безопасным. Мы не хотим хранить пароль и другой защищенный токен в БД онлайн-портала, поэтому мы используем CAS для аутентификации и авторизации. Во время регистрации, когда пользователь выбирает пароль, мы храним пароль в CAS и сохраняем соответствующий токен в БД портала
При входе пользователя в следующий раз пользователь вводит имя пользователя и пароль в Portal. Портал получает маркер, соответствующий пользователю из БД, и отправляет имя пользователя, пароль и токен в CAS для проверки.
Но, если пользователь уже зарегистрировался в одном приложении и перенаправляет пользователя в другое приложение, мы не хотим, чтобы пользователь снова вводил имя пользователя и пароль для второго приложения. Мы используем SAML для решения этой проблемы. Первое приложение делится сведениями пользователей с сервером SAML и получает токен взамен. Первое приложение передает токен второму приложению. Второе приложение отправляет токен на сервер SAML, чтобы получить информацию о пользователе и при успешном завершении работы пользователя на желаемой странице. Наше первое приложение может быть мобильным приложением, а второе может быть Portal в сценарии App2Web.