SSO с CAS или OAuth?

Question

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

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

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

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

Контекст:

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

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

Добавление

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

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

Answer 1

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

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

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

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

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

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

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

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

[обновлено]

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

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

Answer 2

Я склонен думать об этом так:

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

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

Answer 3

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

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

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

Answer 4

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

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

Answer 5

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

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

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