Проверка подлинности на основе утверждений в SharePoint и вообще

все,

Я много читал вокруг проверки подлинности на основе утверждений и все еще немного смущен. Я пытаюсь укрепить свое понимание, особенно в отношении SharePoint 2010/2013, но и в целом (т. е. ASP.NET).

мое понимание различных частей терминологии технологии выглядит следующим образом:

  • WIF (Windows Identity Foundation) - библиотека .NET (набор API), используемая для использования утверждений идентификаторов и здание изготовленное на заказ STSs etc.

  • проверяющая сторона - "потребитель" утверждений (т. е. SharePoint, ASP.NET вебсайт etc.). Претензии предоставляются через STS (только IP-STS?).

  • STS (Security Token Service) - специализированная веб-служба, которая выдает маркеры безопасности. Поставляется в двух вкусах, и некоторые STSs, возможно, оба вкуса одновременно?

    • RP-STS (служба маркеров безопасности проверяющей стороны)
    • IP-STS (Служба Маркеров Безопасности Поставщика Удостоверений)
  • доверенный поставщик удостоверений (терминология SharePoint) - он же. IP-STS.

  • SharePoint 2010/2013 STS-приложение Службы SharePoint, разработанное с использованием WIF, которое действует только как RP-STS. Действует как подключаемая точка агрегации для нескольких настраиваемых доверенных поставщиков удостоверений (IP-STSs). При необходимости они могут быть построены вручную с использованием WIF.

  • ADFS 2.0 - роль Windows, разработанная специально для объединения orgnanisation только с экземпляром Active Directory. Предоставляет конечную точку IP-STS, построенную с помощью WIF. Мое понимание ADFS 2.0 заключается в том, что он не позволяет вам "агрегировать" других поставщиков удостоверений - он просто позволяет вам аутентифицироваться на определенном экземпляре AD, который может быть не локальным для вас и поэтому должен быть федеративным для поддержки SSO.

  • Windows Azure ACS 2.0-служба специально для Федерация любых настроенных сторонних поставщиков удостоверений (например, учетная запись Microsoft, Google, Facebook, ADFS 2.0). Действует как подключаемая точка агрегации для других поставщиков удостоверений, для которых она действует как проверяющая сторона. Предоставляет конечную точку IP-STS, построенную с помощью WIF. Поставщики удостоверений, которые он агрегирует, не обязательно IP-STSs, но ACS 2.0 предоставляет все через утверждения, используя свои встроенные IP-STS.

с SharePoint 2010/2013 вопросы:

мой главный проблема в том, что я видел несколько статей, говорящих об ADFS 2.0 и SharePoint, которые почти читают, как будто вы замена встроенный SharePoint 2010/2013 STS с ADFS 2.0! Надеюсь, это только мое чтение, но оно смутило мое понимание.

  1. вы действительно можете это сделать? Я не вижу причин, почему вы не могли бы, если бы действительно хотели, но я предполагаю, что вам нужно отключить SharePoint STS и сделать много ручной конфигурации?
  2. почему вы хотите сделать это?

2.1. Проверка подлинности AD уже поддерживается как параметр поставщика надежных удостоверений OOTB SharePoint STS, и если вы хотите использовать ADFS 2.0, вместо этого вы можете просто добавить его в качестве надежного поставщика удостоверений (IP-STS), для которого я видел сообщения в блоге.

2.2. Основываясь на моем описании ADFS 2.0, Изменение его для SharePoint STS фактически даст вам менее гибкое решение?

отчетность:

  • вы можете настройте SharePoint STS для использования ADFS 2.0 A доверенного поставщика удостоверений (IP-STS), а также или вместо локального AD.
  • можно настроить SharePoint STS для использования Windows Azure ACS 2.0 A доверенный поставщик удостоверений (IP-STS). Это позволит очень легко поддерживать сторонних поставщиков аутентификации без разработки собственных IP-STS с помощью WIF.

ASP.NET WIF вопросы:

  1. Я понимаю, что для того, чтобы выполнить доверие переговоры и обмен утверждениями RP-STS должны разговаривать с IP-STS. Правильно ли это?
  2. поэтому в контексте построения на основе утверждений ASP.NET веб-приложение (проверяющая сторона) при использовании WIF поэтому вы должны разработать/повторно использовать и включить RP-STS в приложение и cnfigure это, чтобы иметь доверительные отношения с IP-STS? Если нет, вы можете получить удостоверение непосредственно от IP-STS с помощью WIF?

просто написание этого помогло мне выбросить это из головы, но любой справка по inaccuracices/за упрощение/откровенная ложь будут с благодарностью оценили!

с уважением,

Майкл Тейлор

1 ответов


SP STS является RP-STS, т. е. у него нет хранилища учетных данных для аутентификации. Вот почему вы должны объединить его с ADFS, который является IP-STS, т. е. он аутентифицируется против объявления в его домене.

ADFS может быть RP-STS или IP-STS, например, у вас может быть приложение path - SP. - >SP STS - > ADFS (RP) -> ADFS (IP) -> AD.

IP-STS, который вы объединяете с SP, не должен быть ADFS - это может быть все, что поддерживает протокол WS-Federation, например OpenAM, PingIdentity, Azure ACS. Главное, что в конце цепочки должно быть хранилище учетных данных для аутентификации.

это хранилище учетных данных не должно быть AD, например ADFS - > IdentityServer - > SQL Server.

ADFS могут быть объединены со многими различными IP-STS. Пользователь может выбрать, какой из них использовать для проверки подлинности.

ADFS поддерживает протоколы Федерации SAML2 и WS-Fed. SP RP-STS поддерживает только С WS-ФРС.

предыдущая версия ADFS (т. е. 1.0) - это версия, установленная на Windows Server 2008. Вы должны скачать ADFS 2.0. К сожалению, есть несколько сообщений в блоге, которые используют термин ADFS, но которые относятся к ADFS 1.0. Будьте осторожны-ADFS 1.0-совершенно другой зверь.

WIF-это просто набор классов .NET. Это не СТС. Вы можете пойти WIF - > IP-STS или WIF - > RP-STS- > IP-STS и т. д.

надеюсь, это ответило на некоторые из ваших вопросов но стреляйте, если что-то еще не ясно.

обновление:

единственные STS, которые я знаю о том, что включают WIF, - это ADFS и IdentityServer. Большинство из них, упомянутых выше, основаны на Java.

причина, по которой вы выбрали бы ADFS над IWA, заключается в том, что оба аутентифицируются против AD, но только ADFS добавляет SSO и функциональность Федерации. Также ADFS предоставляет все утверждения на основе сантехники-токен SAML и т. д.

когда вы федеративно ADFS, вы предоставьте возможность проверки подлинности в нескольких хранилищах учетных данных. Но если вы решите аутентифицировать экземпляр ADFS, он будет использовать репозиторий AD. При установке ADFS он находит экземпляр AD в своем домене. Это тот, который он использует.