#.net #azure #wif #access-control #geneva-framework
#.net #azure #wif #управление доступом #geneva-framework
Вопрос:
В настоящее время у нас есть несколько.Сетевые приложения в разных доменах с отдельным членством в каждом. Мы переходим к федеративному входу с единым входом (и, надеюсь, с единым выходом) и централизованным членством, размещенным в Azure.
Естественным выбором для нас, казалось, было создание нашего собственного поставщика удостоверений для Azure Access Control, который все наши сайты аутентифицировали бы с помощью WIF, но может быть возможность отсутствия .Сетевым сайтам в будущем придется проходить аутентификацию с помощью этого.
Является ли это все еще приемлемым маршрутом?
Ответ №1:
ACS является «Поставщиком федерации». Это в основном позволяет вашим «проверяющим сторонам» (вашим приложениям) делегировать ему аутентификацию.
ACS сама может доверять многим «поставщикам удостоверений», включая вашего, если хотите. В настоящее время (ACS V2) поддерживает WS-Федерацию и OpenID (для веб-сайтов), WS-Доверие и 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 app, полагающийся на ACS / ACS, полагающийся на поставщика удостоверений без MSFT.
Если вы хотите сохранить свои базы данных участников для аутентификации (это означает, что у вас все равно будут имя пользователя / пароли), вы можете обернуть это STS (созданным с помощью WIF) и добавить его в список поставщиков удостоверений. Тогда любое приложение (.NET или нет) может использовать аутентификацию на его основе:
Конечно, вы можете объединить оба: заставить ваши приложения доверять ACS, а затем ACS доверять вашему IdP (в дополнение к другим IDP). Это дает вам дополнительную гибкость.
В общем, если вы используете WIF на своем веб-сайте на базе .NET, вам не нужно писать много кода (если он есть). Все просто работает.
Примеры всего этого доступны здесь:
- Набор для обучения идентификации
- Руководство по идентификации на основе утверждений (http://claimsid.codeplex.com)
Для очень краткого ознакомления ознакомьтесь с последней веб-трансляцией Скотта:http://scottdensmore.typepad.com/blog/talks.html
Ответ №2:
ОЙ я увлекся и заметил, что часть проверяющих сторон ПОСЛЕ того, как я написал ответ! Однако последняя часть остается в силе. ACS использует REST и выдает токены SAML или SWT, поэтому любое приложение, которое их понимает, может использовать ACS.
WIF и ACS не требуются.NET на сайте клиента. На самом деле самый простой способ использовать это — через службы федерации AD, которые аутентифицируют пользователей в их домене AD и передают токен SAML в ACS.
Фактически, ACS SDK содержит статьи по настройке ACS для использования Google, Facebook и Yahoo в качестве поставщиков удостоверений.
Если вам нужно пройти аутентификацию в другой системе (например, внутренней системе единого входа, базе данных, что угодно), вы можете написать своего собственного поставщика удостоверений, который будет проверять подлинность пользователя и отправлять соответствующие токены в ACS. Поскольку ACS использует REST API, вы можете использовать любую платформу или язык, которые вам нравятся, для создания своего провайдера.
Комментарии:
1. Всего пара исправлений: REST — не единственный протокол, включенный в ACS. Он также может выполнять SOAP (WS-trust) и WS-Fed. Для использования WIF обычно требуется компьютер с Windows .NET.
2. Да, следовало бы помнить об этом!
Ответ №3:
Если под «не на основе СЕТИ» вы подразумеваете что-то вроде Java-приложений, вы можете объединить Java (например, используя OpenSSO или PingFederate) и ADFS.
ADFS может объединяться с ACS.
Существует ряд пошаговых руководств по совместимости с ADFS 2.0
Я не уверен, что вы могли бы удалить ADFS и просто объединить ACS с этими другими продуктами вместо них? Есть комментарии?