SSO с CAS или OAuth?

Question

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

Контекст:

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

У меня только discovered 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 не относится к Single Sign-On (и не заменяет протокол CAS). Речь идет не о : контролирует доступ пользователя. Речь идет о предоставлении пользователю для управления тем, как их ресурсов могут быть доступны сторонними организациями. Два очень разных варианта использования.

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

[обновлено]

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

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

Answer 2

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

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

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

Answer 3

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

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

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

Answer 4

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

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

Answer 5

Для меня, реальная разница между ССО и OAuth является предоставление, а не аутентификации , поскольку сервер, который реализует OAuth очевидно имеет аутентификации (вы должны войти в свой Google, OpenId или Facebook для OAuth, чтобы произойти с клиентским приложением)

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

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

(мои 2 цента)