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

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

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

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

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

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

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

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

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

EDIT: я нашел лучший простой объяснение того, как CAS работает наhttp://www.jasig.org/cas/proxy-authentication (остальная часть страницы говорит о проксированной аутентификации. Что более сложно, но первые несколько абзацев-это простой случай, о котором мы говорим здесь)

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

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

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

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

теперь, реализация мудрая, SSO requries две области для оценки: -

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

b) как информация SSO должна поступать между сторонами? Ofcouse надежно в большинстве сценариев.

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

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

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

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

клиент --> в доме централизованного 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) клиент веб-службы будет вызывать SSO на уровень централизованного движка (реализованный в любой технологии), который может выполнять проверки и бухгалтерию и может быть основан на исходном домене (например, my-java-app.com) во входящем XML делегирует запрос поставщику OAuth2, такому как facebook-connect. Таким образом, ваш движок, принимающий решения, будет управлять правилами аутентификации, как вы упомянули в своем требовании.

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