Простой SSO - с использованием пользовательской аутентификации - CAS или какой-то сервер Oauth или openid?

Oauth предназначен для аутентификации приложений, чтобы они могли действовать от имени пользователя. Например, твиттер-клиент может публиковать твиты с учетной записью пользователя. Его можно использовать для единого входа, как показывает Facebook, но это требует дополнительной работы.

Сравнение CAS и OpenID

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

OpenID имеет два (несовместимых) стандарта для предоставления дополнительных атрибутов учетной записи, которые более или менее поддерживаются общими библиотеками. В стандартной настройке CAS предоставляет только имя пользователя. Хотя CAS теоретически поддерживает обмен атрибутами, на данный момент его поддерживает только клиент PHP < / а>.

К счастью, и OpenID, и CAS допускают прозрачную попытку входа. В этом режиме форма входа не отображается. Браузер немедленно перенаправляется обратно с информацией для аутентификации или без нее. Другими словами: вы можете перенаправить всех новых пользователей (без сеанса) провайдеру идентификации, как только они посетят ваш сайт. Есть хорошая диаграмма, объясняющая это. в деталях. CAS называет это «режимом шлюза», и это достигается добавлением gateway = true к URL-адресу входа. В OpenID это называется «немедленный режим», а параметр URL - openid.mode = checkid_immediate.

CAS поддерживает единый выход. OpenID - нет.

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

Ответы

Во-первых, я не понимаю необходимости проверки токенов CAS, для чего это нужно?

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

Следует ли клиентам также использовать ssl?

да.

На стороне клиента вы бы использовали iframe, например лайтбокс, для отображения перенаправленной страницы? Почему, почему нет?

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

У iframe есть проблема, от которой необходимо избавиться после завершения входа в систему. Для CAS существует руководство о том, как вставьте форму входа CAS в HTML-код приложения. Другой альтернативой является отображение всплывающего окна, как это делает Facebook Connect.

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

Во-первых, я не понимаю необходимости проверки токенов CAS, для чего это нужно?

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

Это более безопасно? Я отмечаю, что он основан на перенаправлении и, следовательно, в равной степени подвержен атаке «злоумышленник в середине», как и пользовательский сервер аутентификации без дополнительного шага проверки токена. Я что-то упускаю из-за безопасности в CAS?

Серверы аутентификации используют SSL для предотвращения атак MitM. Но я не понимаю, как эта проблема связана с SSO / CAS, поскольку у вас будет такая же проблема, даже если приложение выполняет собственную аутентификацию. Возможно, вы расскажете нам, какие атаки MitM вас беспокоят с настройкой CAS.

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

Токены - это всего лишь способ для приложения аутентифицировать вас без вашего пароля. Это короткий срок службы / одноразовый токен, связанный с вашими учетными данными. Приложение предоставляет маркер серверу CAS, и сервер CAS отвечает с учетными данными, если они связаны с ним. Единый выход и тайм-аут возможны, но не связаны напрямую с наличием токенов.

Надеюсь, это понятно. Я попытался дать объяснение на высоком уровне. Не стесняйтесь спрашивать подробности, если есть какая-то часть, которая неясна, или вы хотите получить более подробную информацию.

РЕДАКТИРОВАТЬ: я нашел более простое объяснение того, как работает CAS, на http://www.jasig.org/cas/proxy-authentication (Остальная часть страницы говорит о прокси-аутентификации. Это более сложно, но первые несколько абзацев представляют собой простой случай, о котором мы говорим здесь)

Я захожу в свой экземпляр Portal. Он перенаправляет меня в CAS для входа в систему. CAS обнаруживает мой защищенный файл cookie и выполняет единый вход, в результате чего мне не нужно повторно указывать свое имя пользователя и пароль. CAS перенаправляет меня обратно на портал. Портал проверяет билет, регистрирует меня на портале. Я вижу, что мой макет по умолчанию заполнен некоторыми классными каналами, которые говорят мне, что на улице действительно холодно и что в новостях.

Обратите внимание, что портал не получил мой пароль.

Это основано на моем опыте: SSO (единый вход) связан с двумя сценариями: - i) Я очень хорошо вас знаю (задействованы две стороны) ii) Привет, друг, познакомьтесь с моим другом (задействованы три стороны)

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

Теперь, с точки зрения реализации, SSO требует оценки двух областей:

a) как разные стороны / системы (внутренние / внешние по отношению к рассматриваемой организации) управляют учетными данными пользователей. Это называется управлением идентификацией.

б) как информация SSO должна передаваться между сторонами? Конечно, в большинстве случаев это безопасно.

Я думаю, что управление идентификацией более важно, чем определение того, как безопасно передавать информацию, потому что для последней части доступно множество методов шифрования / дешифрования. Это управление неопределенностью, которое разительно отличается в одном наборе систем с поддержкой SSO.

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

@Ole, сказав все выше об основах единого входа (с моей точки зрения), я думаю, вам следует больше сосредоточиться на том, как пользователи и их роли идентифицируются в нескольких системах, то есть в вашем случае: - ваши пользователи хранят, откройте провайдер outh2; так что подумайте об управлении идентификацией.

Одним из решений может быть (в зависимости от вашего бюджета и времени), ваше предприятие может потратить усилия на создание собственного централизованного интерфейса аутентификации в форме стандартных технологий интеграции, например, веб-службы и за этим API вы можете иметь любую реализацию: ваш собственный провайдер или сторонний oAuth или их сочетание. Вы можете реализовать уровень движка между вашим API и уровнем провайдера, который принимает решения. Например, Engine может иметь домен приложения и соответствующее сопоставление поставщика аутентификации. Таким образом, у вас будет единый интерфейс аутентификации для всех клиентов.

Клиент -> Внутренний централизованный API -> Движок -> Провайдеры аутентификации, позвольте мне привести пример: - i) вы можете открыть веб-сервис, имя может быть singleSigonService. Полезные данные XML могут быть такими: -

<SingleSignOnReqType>   <sourceID>XYZ</sourceID>    <source-domain>my-java-app.com</source-domain>  <user-credentials>...</<user-credentials>
        <security-credentials>...</<security-credentials> </SingleSignOnReqType>

ii) Клиент веб-службы будет выполнять вызов единого входа на уровень централизованного механизма (реализованный в любой технологии), который может выполнять проверки и бухгалтерский учет и может быть основан на исходном домене (например, my-java-app.com) во входящем XML. делегирует запрос провайдеру Oauth2, например facebook-connect. Таким образом, ваш движок, принимающий решение, будет управлять правилами аутентификации, как вы упомянули в своем требовании.

Таким образом, в основном все потребительские приложения будут иметь единый интерфейс на основе веб-сервисов для вашего решения SSO. Это то, что я имею в виду под внутренним централизованным API.