SSO с CAS или OAuth?


186

Интересно, следует ли мне использовать протокол CAS или OAuth + какой-нибудь провайдер аутентификации для единого входа.

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

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

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

Контекст:

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

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

Дополнение

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

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


6
Единый выход - это анти-функция. Все исследования пользователей, о которых я знаю, которые касались этого, показали, что это где-то от легкого до чрезвычайно запутанного как для новичков, так и для опытных пользователей. Лично мне приходится использовать систему, которая использует систему единого выхода на ежедневной основе, и меня это невероятно раздражает. Я почти никогда не хочу такого поведения.
Боб Аман,

16
Не соглашайтесь с тем, что единый выход - это антифункция. Все зависит от рассматриваемых приложений. Для веб-приложений, которые так или иначе связаны друг с другом, то есть почты Google и календаря Google, имеет смысл, если вы явно выходите из одного, вы выходите из другого. В случаях с приложениями, в которых нет явной «взаимосвязи», я согласен с Бобом.
Ashwoods

6
Обратите внимание, что этот вопрос изначально задавался до того, как был представлен OAuth 2.0, поэтому информация, связанная с OAuth, может больше не соответствовать действительности.
Эндрю

Ответы:


240

OpenID не является «преемником» или «заменой» CAS, они разные по назначению и реализации.

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

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

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

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

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

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

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

[обновлено]

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

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


11
Хотя OAuth в основном предназначен для авторизации, его можно использовать как центральный сервер аутентификации. Подобно тому, как учетная запись Google OAuth используется многими сайтами (включая SO) для аутентификации, без фактического использования какой-либо службы от поставщика OAuth.
Амир Али Акбари,

1
Более того, как сказано в ответе Bertl, CAS теперь предоставляет OAuth как клиент, так и сервер.
Энтони О.

3
Актуален ли этот ответ сейчас, когда существует OAuth 2.0? Как ваше мнение изменилось с OAuth 2.0?
Эндрю

6
OAuth 2.0 по-прежнему является протоколом авторизации, а не протоколом аутентификации, но его можно построить поверх OAuth 2.0 для создания протокола аутентификации, что и сделали Facebook / LinkedIn и т. Д.; единственное стандартизованное расширение OAuth 2.0, обеспечивающее аутентификацию, - это OpenID Connect, назначенный преемник OpenID
Ханс З.

48

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

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

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


6
OpenID - это протокол аутентификации, OAuth - протокол авторизации.
zenw0lf

13

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

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

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


8

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

В SSO опытный пользователь / системный администратор заранее предоставляет конечному пользователю доступ к приложению в «приложении SSO». В OAuth конечный пользователь предоставляет приложению доступ к своим «данным» в «приложении OAuth»

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


7

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

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


3
Для людей , просматривающих это и возможно спутать, то CASупомянутые здесь CAS сервер вместо протокола CAS .
Ng Sek Long
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.