SSO с CAS или OAuth?
Интересно, должен ли я использовать протокол CAS или OAuth + некоторый поставщик аутентификации для единой точки входа.
Сценарий в качестве примера:
- Пользователь пытается получить доступ к защищенному ресурсу, но не аутентифицируется.
- Приложение перенаправляет пользователя к серверу SSO.
- Будучи аутентифицируемым пользователь получает маркер от сервера SSO.
- SSO перенаправляет к исходному приложению.
- Исходное приложение проверяет маркер по серверу SSO.
- Если маркер будет в порядке, то доступ будет предоставлен, и приложение знает об идентификаторе пользователя.
- Пользователь выполняет выход из системы и зарегистрирован из всего связанного приложения одновременно (единственный, выписываются).
Насколько я понимаю, что это точно, что было CAS, изобретенным для. Клиенты CAS должны реализовать протокол CAS для использования услуги аутентификации. Теперь я задаюсь вопросом собирающийся использование CAS или OAuth в клиенте (потребитель) сайт. Действительно ли OAuth является заменой для той части CAS? Должен OAuth как новый фактический стандарт быть предпочтенным? Есть ли простое в использовании (не Sun OpenSSO!) замена для части аутентификации CAS, поддерживающего различные методы как имя пользователя/пароль, OpenID, TLS certifactes...?
Контекст:
- Различные приложения должны полагаться на аутентификацию сервера SSO и должны использовать что-то подобное сессии.
- Приложения могут быть веб-приложениями GUI или (REST) serivces.
- Сервер SSO должен быть, обеспечивают идентификатор пользователя, который необходим для получения большей информации о пользователе как роли, электронная почта и так далее от центрального пользовательского банка сообщений.
- Единственный Выписываются, должно быть возможным.
- Большинство клиентов записано в Java или PHP.
Я только что обнаружил, ПЕРЕНОСЯТСЯ, который мог стать преемником OAuth. Это - новый протокол, указанный Microsoft, Google и Yahoo.
Приложение
Я узнал, что OAuth не был разработан для аутентификации, даже это могло использоваться для реализации SSO, но только вместе с сервисом SSO как OpenID.
OpenID, кажется, мне "новый CAS". CAS имеет некоторые функции OpenID промахи (как сингл, выписываются), но это не должно быть к трудно для добавления недостающих частей в конкретном сценарии. Я думаю, что OpenID имеет широкое принятие, и лучше интегрировать OpenID в приложения или серверы приложений. Я знаю, что CAS также поддерживает OpenID, но я думаю, что CAS необязателен с OpenID.
3 ответа
OpenID не является "преемником" или "заменой" CAS, они разные, по замыслу и по реализации.
CAS централизует аутентификацию. Используйте его, если вы хотите, чтобы все ваши (вероятно, внутренние) приложения просили пользователей войти на один сервер (все приложения настроены так, чтобы указывать на один сервер CAS).
OpenID децентрализует аутентификацию. Используйте его, если вы хотите, чтобы ваше приложение позволяло пользователям входить на любой сервис аутентификации, который они захотят (пользователь предоставляет адрес сервера OpenID - фактически, "имя пользователя" является URL сервера).
Ни один из вышеперечисленных сервисов не работает с авторизацией (без расширений и/или кастомизации).
OAuth обрабатывает авторизацию, но не заменяет традиционную таблицу 'USER_ROLES' (доступ пользователя). Он обрабатывает авторизацию для третьих лиц.
Например, вы хотите, чтобы ваше приложение интегрировалось с Twitter: пользователь может разрешить ему автоматически отправлять твиты, когда он обновляет свои данные или публикует новый контент. Вы хотите получить доступ к какому-то стороннему сервису или ресурсу от имени пользователя, не получая его пароля (что, очевидно, небезопасно для пользователя). Приложение запрашивает у Twitter доступ, пользователь авторизует его (через Twitter), после чего приложение может получить доступ.
Итак, OAuth - это не единый вход (и не замена протокола CAS). Речь идет не о том, чтобы вы контролировали, к чему пользователь может получить доступ. Речь идет о том, чтобы позволить пользователю контролировать, как его ресурсы могут быть доступны третьим лицам. Два совершенно разных случая использования.
В контексте, который вы описали, CAS, вероятно, является правильным выбором.
[updated]
Тем не менее, вы можете реализовать SSO с помощью OAuth, если вы рассматриваете личность пользователя как защищенный ресурс. В принципе, именно это и делает "Sign up with GitHub" и тому подобное. Возможно, это не было первоначальным замыслом протокола, но это можно сделать. Если вы контролируете сервер OAuth и ограничиваете приложения только аутентификацией на нем, это и есть SSO.
Однако стандартного способа принудительного выхода из системы нет (в CAS такая возможность есть).
Настоятельно введите Html Helpers .
Больше никаких «магических последовательностей» для передачи имени свойства в помощник не означает больше проверки времени компиляции, меньше потраченного времени на отладку.
-121--4780393-Зоны !!!
Использование областей в новой системе CMS публикации для поддержания контроллера администрирования/представлений отдельно от обычного переднего плана сайта.
Сильно набранные помощники тоже хороши. (См. ответ @ womp)
Запись в блоге Скот Гу на MVC 2
-121--4780399-OpenID является протоколом аутентификации, OAuth и OAuth WRAP являются протоколами авторизации. Они могут быть объединены с гибридным расширением OpenID .
Я бы очень предпочел, чтобы люди строили на основе стандартов, которые имеют большой импульс (больше доступной поддержки, легче привлечь третьи вечеринки), даже если они не точно подходят для данного приложения. В этом случае OAuth имеет импульс, а не CAS. Вы должны быть в состоянии сделать все или, по крайней мере, почти все, что вам нужно сделать с OAuth. В какой-то более поздний пункт в будущем, OAuth WRAP должен упростить вещи дальше (он делает некоторые достойные компромиссы, используя маркер носителя и толкая шифрование вниз на уровень протокола), но он все еще находится в зачаточном состоянии, и тем временем, OAuth, вероятно, будет делать работу просто хорошо.
В конечном счете, если вы решите использовать OpenID и OAuth, у вас и у всех, кто нуждается в интеграции с системой, будет больше библиотек для большего количества языков. У вас также гораздо больше глазных яблок смотрят на протоколы, чтобы убедиться, что они действительно так же безопасны, как и должны быть.
Я склонен думать об этом таким образом:
Используйте CAS, если вы управляете системой аутентификации пользователя и должны поддерживать гетерогенный набор серверов и приложений, которые требуют централизованной аутентификации.
Используйте OAUTH Если вы хотите поддержать аутентификацию пользователя из систем, которые у вас нет / поддержка (т. Е. Google, Facebook, и т. Д.).