SSO с CAS или OAuth?

Интересно, следует ли мне использовать протокол 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.

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

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

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

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

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

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

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

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

[обновлено]

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

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

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

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

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

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

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

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

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

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

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

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

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