Подходит ли Azure Access Control и WIF, если некоторые из проверяющих сторон не основаны на .Net

Question

В настоящее время у нас есть несколько приложений .Net в разных доменах с отдельным членством в каждом.Мы переходим к федеративному входу в систему с единым входом (и, возможно, единым выходом) и централизованным членством, размещенным в Azure.

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

По-прежнему ли это приемлемый маршрут?

Answer 1

ACS является «федеральным провайдером».По сути, это позволяет вашим «проверяющим сторонам» (вашим приложениям) делегировать ему аутентификацию.

ACS может сам доверять многим «провайдерам идентификации», в том числе вашим, если хотите.В настоящее время (ACS V2) поддерживает WS-Federation и OpenID (для веб-сайтов), WS-Trust & OAuth (для веб-служб).Это «протоколы».ACS поддерживает 2 формата токенов: SAML (1.1 и 2.0) и SWT.Он также поставляется с предварительно настроенными Google, Yahoo !, Facebook и LiveID.

Если ваше приложение доверяет ACS, вы можете принимать пользователей с учетными записями в любой из этих служб.ACS может работать с «любым» IdP, который поддерживает любой из этих протоколов.

WIF - это платформа для .NET, которая позволяет "утверждать" ваше приложение и без проблем работает в таких стеках, как ASP.NET (и ASP.NET MVC) и WCF.Он может работать с другими стеками приложений, но требует взаимодействия.Однако каждая платформа обычно имеет WIF-эквивалент, и, если она соответствует стандарту (например, WS-Fed, токены SAML и т. Д.), Она работает.

Взаимодействие тоже в обе стороны.Например: приложение не .NET, полагающееся на ACS / ACS, полагающееся на поставщика удостоверений без MSFT.

Если вы хотите сохранить свои базы данных членства для аутентификации (это означает, что у вас все еще будут имена пользователей и пароли),Вы можете обернуть его с помощью STS (построенного с WIF) и добавить его в список провайдеров идентификации.Тогда любое приложение (.NET или нет) может использовать аутентификацию на его основе:

Конечно, вы можете комбинировать и то и другое: ваши приложения доверяют ACS, а затем ACS доверяют вашему IdP (В дополнение к другим IdP).Это дает вам дополнительную гибкость.

Как правило, если вы используете WIF на своем веб-сайте на основе .NET, вам не нужно писать много кода (если он есть).Все просто работает.

Примеры всего этого доступны здесь:

• Identity Training Kit
• Руководство по идентификации на основе утверждений (http://claimsid.codeplex.com)

Для очень быстрого вступления, проверьте последнюю веб-трансляцию Скотта: http://scottdensmore.typepad.com/blog/talks.html

Answer 2

Если под «не на основе NET» вы подразумеваете что-то вроде приложений Java, вы можете объединять Java (например, используя OpenSSO или PingFederate) и ADFS.

ADFS может объединяться с ACS.

Существует ряд пошаговых руководств по совместимости ADFS 2.0

Я не уверен, что вы могли бы удалить ADFS и просто объединить ACS с этими другими продуктами?Есть комментарии?

Answer 3

OUCH Я увлекся и заметил проверяющие стороны часть ПОСЛЕ того, как я написал ответ!Последняя часть имеет место, хотя.ACS использует REST и выдает SAML или SWT токены , поэтому любое приложение, которое их понимает, может использовать ACS.

WIF и ACS не требуют .NET на сайте клиента.На самом деле его проще всего использовать через Службы федерации AD , которые проверяют подлинность пользователей в их домене AD и передают токен SAML в ACS.

Фактически, SDK ACS содержит статьи по настройкеACS для использования Google , Facebook и Yahoo в качестве поставщиков удостоверений.

Если вам нужно пройти аутентификацию в другой системе (например, во внутренней системе единого входа, в базе данных и т. Д.), Вы можете написать своего собственного провайдера идентификации, который будет аутентифицировать пользователя и отправлять соответствующие токены в ACS.Поскольку ACS использует REST API, вы можете использовать любую платформу или язык для создания своего провайдера.