SSO с CAS или OAuth?

Интересно, следует ли использовать протокол CAS или OAuth + поставщик проверки подлинности для единого входа.

Пример сценария:

  • Пользователь пытается получить доступ к защищенному ресурсу, но не аутентифицирован.
  • Приложение перенаправляет пользователя на сервер SSO.
  • Если аутентификация прошла аутентификацию, пользователь получает маркер с сервера SSO.
  • SSO перенаправляет исходное приложение.
  • Исходное приложение проверяет токен на сервере SSO.
  • Если токен в порядке, доступ будет разрешен, и приложение узнает идентификатор пользователя.
  • Пользователь выполняет выход из системы и одновременно выходит из всех подключенных приложений (один раз).

Насколько я понимаю, именно это и было изобретено CAS. Клиенты CAS должны внедрить протокол CAS для использования службы аутентификации. Теперь мне интересно, как использовать CAS или OAuth на клиентском (потребительском) сайте. Является ли OAuth заменой для этой части CAS? Должен ли OAuth стать новым стандартом де-факто? Есть ли простая в использовании (не Sun OpenSSO!) Замена для части аутентификации CAS, поддерживающей разные методы, такие как имя пользователя/пароль, OpenID, сертификаты TLS...?

Context:

  • Различные приложения должны полагаться на аутентификацию SSO-сервера и должны использовать что-то вроде сеанса.
  • Приложения могут быть веб-приложениями GUI или (REST).
  • Серверу SSO должен быть предоставлен идентификатор пользователя, который необходим для получения дополнительной информации о пользователях, таких как роли, электронная почта и т.д. из центрального хранилища информации пользователя.
  • Должна быть доступна единая регистрация.
  • Большинство клиентов написаны на Java или PHP.

Я только обнаружил WRAP, который может стать преемником OAuth. Это новый протокол, указанный Microsoft, Google и Yahoo.

Добавление

Я узнал, что OAuth не был предназначен для аутентификации, даже если он может быть использован для реализации SSO, но только вместе с SSO-сервисом, таким как OpenID.

OpenID мне кажется "новым CAS". У CAS есть некоторые особенности пропусков OpenID (например, одиночный выход), но не обязательно добавлять недостающие части в конкретный сценарий. Я думаю, что OpenID имеет широкое признание, и лучше интегрировать OpenID в приложения или серверы приложений. Я знаю, что CAS также поддерживает OpenID, но я думаю, что CAS не совместим с OpenID.

ОТВЕТЫ

Ответ 1

OpenID не является "преемником" или "заменяет" для CAS, они разные, в намерениях и в реализации.

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

OpenID децентрализовать аутентификацию. Используйте его, если вы хотите, чтобы ваше приложение принимало логин для входа в любую службу проверки подлинности, которую они хотят (пользователь предоставляет адрес сервера OpenID - фактически, "имя пользователя" - это URL-адрес сервера).

Ни одна из указанных выше авторизаций дескриптора (без расширений и/или настроек).

OAuth обрабатывает авторизацию, но не заменяет традиционную таблицу USER_ROLES (пользовательский доступ). Он обрабатывает авторизацию для сторонних разработчиков.

Например, вы хотите, чтобы ваше приложение интегрировалось с Twitter: пользователь мог позволить ему автоматически чирикать, когда они обновляют свои данные или публикуют новый контент. Вы хотите получить доступ к стороннему сервису или ресурсу от имени пользователя, не получая его пароль (что явно небезопасно для пользователя). Приложение запрашивает Twitter для доступа, пользователь авторизует его (через Twitter), а затем приложение может иметь доступ.

Итак, OAuth не относится к Single Sign-On (и не заменяет протокол CAS). Это не о вам, управляющем доступом пользователя. Речь идет о том, чтобы позволить пользователю управлять доступом к ресурсам сторонних производителей. Два очень разных варианта использования.

В контексте, который вы описали, CAS, вероятно, является правильным выбором.

[обновлено]

Тем не менее, вы можете реализовать SSO с OAuth, если учесть личность пользователя как защищенного ресурса. Это то, что "Подписывайтесь с GitHub", и в основном это нравится. Возможно, это не оригинальное намерение протокола, но это можно сделать. Если вы контролируете сервер OAuth и ограничиваете приложения только аутентификацией с ним, это SSO.

Нет стандартного способа принудительного выхода из системы (CAS имеет эту функцию).

Ответ 2

Я так думаю об этом:

Используйте CAS, если вы управляете/владеете системой аутентификации пользователей и должны поддерживать гетерогенный набор серверов и приложений, которым требуется централизованная аутентификация.

Используйте OAuth, если вы хотите поддерживать аутентификацию пользователей из систем, которые у вас нет/поддерживают (например, Google, Facebook и т.д.).

Ответ 3

OpenID - это протокол аутентификации, OAuth и OAuth WRAP являются протоколами авторизации. Их можно комбинировать с гибридным расширением OpenID .

Я бы предпочел видеть, как люди строятся поверх стандартов, которые имеют большой импульс (более доступная поддержка, проще привлечь третьих сторон), даже если они не подходят для приложения под рукой. В этом случае OAuth имеет импульс, а не CAS. Вы должны иметь возможность делать все или, по крайней мере, почти все, что вам нужно делать с OAuth. В какой-то момент в будущем OAuth WRAP должен упростить ситуацию (он делает некоторые полезные компромиссы, используя токен-носитель и подталкивая шифрование до уровня протокола), но он все еще находится в зачаточном состоянии, и тем временем OAuth вероятно, сделает работу просто отлично.

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

Ответ 4

Старый пост, но это может быть полезно:

CAS 3.5 будет поддерживать oAuth в качестве клиента и сервера. См.: https://wiki.jasig.org/display/CASUM/OAuth

Ответ 5

Для меня реальная разница между SSO и OAuth - это грант, а не аутентификация потому что сервер, который реализует OAuth, очевидно, имеет аутентификацию (вы должны войти в свой google, openId или facebook для OAuth, чтобы произойти с клиентским приложением)

В SSO, мощный пользователь /sysadmin предоставляет конечный пользовательский доступ к приложению заранее в "приложении SSO", В OAuth конечный пользователь предоставляет доступ к своим "данным" в приложении "OAuth"

Я не понимаю, почему протокол OAuth не может использоваться как часть SSO-сервера. Просто выньте экран гранта из потока и дайте серверу OAuth найти грант из базы поддержки db.

(мои 2 цента)