SSO с CAS или OAuth?



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



Пример:




  1. пользователь пытается получить доступ к защищенному ресурсу, но не прошел проверку подлинности.

  2. приложение перенаправляет пользователя на сервер SSO.

  3. если проигрываю проверку подлинности пользователь получает токен от сервера единого.

  4. SSO перенаправляет на оригинал приложение.

  5. исходное приложение проверяет маркер на сервере SSO.

  6. если маркер в порядке, доступ будет разрешен, и приложение знает идентификатор пользователя.

  7. пользователь выполняет выход из системы и выход из всех подключенных приложений одновременно (один выход).


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



контекст:




  • различные приложения должны полагаться на аутентификацию сервера SSO и должны использовать что-то вроде сеанса.

  • приложения могут быть веб-приложения с графическим интерфейсом пользователя или (остальные) служб.

  • сервер SSO должен предоставить идентификатор пользователя, который необходим для получения дополнительной информации о пользователе, такой как роли, электронная почта и т. д. Из центрального хранилища информации о пользователе.

  • единый выход должен быть возможно.

  • большинство клиентов написаны на Java или PHP.


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



дополнительное соглашение



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



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

674   5  

5 ответов:

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 имеет импульс, а не АВАРИЯ. Вы должны быть способны делать все или по крайней мере почти все, что вам нужно сделать с OAuth. В какой-то более поздний момент в будущем OAuth WRAP должен упростить вещи дальше (это делает некоторые стоящие компромиссы, используя токен носителя и толкая шифрование вниз к уровню протокола), но он все еще находится в зачаточном состоянии, и тем временем OAuth, вероятно, будет делать эту работу просто отлично.

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

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

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

для меня реальная разница между SSO и OAuth-это грант, а не аутентификация потому что сервер, который реализует OAuth очевидно и

Comments

    Ничего не найдено.