Аутентификация и идентификация на основе утверждений: что это значит для вас?

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

За последние несколько лет вы, возможно, сталкивались с терминами «идентификация на основе утверждений», «аутентификация на основе утверждений» и «управление доступом на основе утверждений», но что именно это означает? Microsoft представила разработчикам идею модели идентификации, основанной на утверждениях, еще в версии 3.0.NET Framework, как способ решения проблемы, связанной с тем, что приложения аутентифицируют пользователей, не имеющих учетных записей домена Windows.

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

Зачем нам нужна новая модель идентичности?

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

Подумайте об этой аналогии из реальной жизни: вы должны предъявить учетные данные, такие как свидетельство о рождении или паспорт, карту социального страхования и, возможно, другие документы, чтобы получить водительские права или удостоверение личности штата, что похоже на мастер-билет. Водительское удостоверение — это общий документ, удостоверяющий личность, который вы можете предъявить, чтобы получить более конкретный «билет» для использования той или иной услуги — например, для открытия счета в банке. Банк полагается на водительское удостоверение (мастер-билет) и не заставляет вас показывать свидетельство о рождении и карточку социального страхования каждый раз, когда вы хотите обналичить чек. Это удобнее для вас и проще для банка.

Итак, если этот метод отлично работал все эти годы, зачем нам вообще нужна новая модель идентичности? Что произойдет, если у вас есть пользователь, у которого нет этих исходных учетных данных, которые запускают игру? Много лет назад, в «реальном мире», я помню, как мой дедушка рассказывал мне о том, как решить эту проблему. Он родился дома, поэтому больничных записей не было, и он не водил машину по дорогам общего пользования (только тракторы, грузовики и другие сельскохозяйственные орудия в частной собственности). Он работал на ферме своих родителей, и тогда ему не нужно было получать карточку социального обеспечения. Поэтому, когда пришло время, в конце жизни, когда ему нужно было подтвердить свой возраст и дату рождения, у него возникла проблема. В конце концов правительство штата приняло письменные показания под присягой от людей, которые знали его всю жизнь, и рукописную запись в семейной библии, и он смог получить свое удостоверение личности, необходимое для участия в больничной программе, но не без большого много времени и усилий и разочарования.

В мире компьютеров у вас могут быть пользователи за пределами вашей организации, которым нужен доступ к вашим службам, но у них нет учетных записей в вашем домене Windows, поэтому им не хватает первого набора учетных данных, от которого зависит процесс Kerberos. Что вы с ними делаете?

Сегодня, а тем более в ближайшие годы, все вычисления будут связаны с облаком. А облачные вычисления еще больше усложнят проблему аутентификации пользователей в разных организациях и сетях. У большинства из нас есть несколько цифровых идентификаторов для разных приложений и служб, и одна и та же идентификационная информация может быть представлена им совершенно по-разному. Разработчикам приложений нужен лучший способ обеспечить правильную аутентификацию пользователей, и в этом заключается идея аутентификации и идентификации на основе утверждений.

Как работает идентификация на основе утверждений

Основой идентичности, основанной на утверждениях, являются, как следует из названия, утверждения. Этот термин используется в данном контексте как название того, что те из нас, кто знаком со схемой Active Directory, могут считать атрибутами. Как только вы это поймете, прояснится много тайн, связанных с идентичностью, основанной на утверждениях.

Словарное определение «притязания» — это «утверждение истинности чего-либо». Претензия, таким образом, — это отдельная часть информации об отдельном пользователе, которую тот, кто делает претензию, утверждает как истинную. Конкретное утверждение само по себе может быть или не быть уникальным для этого человека. Одно утверждение будет именем пользователя, другое утверждение будет его/ее возрастом, третье будет его/ее полом, третье будет его/ее ролью в организации и так далее. Однако утверждения — это не просто дескрипторы; право пользователя на доступ к конкретному серверу или файлу также может быть представлено как претензия.

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

Маркеры безопасности часто (но не всегда) используют SAML (язык разметки ассоциации безопасности), который построен на стандарте XML.

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

1. Пользователь запрашивает доступ к приложению или сервису.
2. Приложение или служба отправляет запрос маркеру для этого пользователя в STS.
3. STS аутентифицирует пользователя (например, с помощью пароля, смарт-карты или биометрического сканирования).
4. STS генерирует токен.
5. STS подписывает токен цифровой подписью, и цифровая подпись становится частью токена.
6. STS возвращает токен приложению или службе, которые его запросили.
7. Приложение проверяет, действительна ли цифровая подпись и что она исходит от STS, которой доверяет приложение (каждое приложение будет иметь список доверенных STS).
8. Приложение обрабатывает информацию об утверждениях, чтобы определить, разрешить ли пользователю доступ к службе или приложению, и какой уровень доступа будет у пользователя.

Преимущество идентификации на основе утверждений

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

Надежные поставщики

Это подводит нас к очевидному вопросу: кому (какой организации) следует в первую очередь доверить проверку личности и выпуск токенов? В компании или другой организации сама компания может выступать в качестве поставщика удостоверений.

Если ваша организация и другая организация имеют доверительные отношения и хотят, чтобы пользователи из двух разных компаний могли получать доступ к ресурсам в сетях обеих компаний, вы можете настроить отношение федеративной идентификации, при котором ваши службы и приложения доверяют STS другой компании и наоборот. наоборот Идентификация на основе утверждений упрощает это, даже если в сетях компаний используются разные операционные системы и протоколы аутентификации. STS аутентифицирует пользователей с помощью любых протоколов, которые используют их компании, а затем выдает маркеры SAML, поэтому не имеет значения, использует ли одна компания сеть домена Windows, а другая нет.

Для доступа к ресурсам за пределами компании, таким как общедоступные сайты социальных сетей, вы, как правило, будете использовать поставщиков, управляемых этими сайтами. Крупные компании, такие как Microsoft и Google, управляющие множеством различных интернет-сервисов, перешли к объединению своих сервисов идентификации. Это означает, что вместо того, чтобы входить в несколько разных служб по отдельности (например, в учетную запись Hotmail и учетную запись SkyDrive), вы входите во все из них с помощью учетной записи Windows Live ID. Точно так же ваша учетная запись Google дает вам доступ к вашей учетной записи Gmail, Google+, Google Voice и так далее.

Святой Грааль — это «единая личность, которая управляет ими всеми», более известная как единый вход (SSO). Проблема заключалась в следующем: какой организации все доверяют выполнять роль универсального поставщика удостоверений? Кто-то может доверять Google, а кто-то доверять Microsoft. Третьи могут не доверять ни тому, ни другому, но доверять Facebook. Следует ли возлагать эту задачу на правительства, которые, в конце концов, выдают удостоверения личности «реального мира»?

С идентификацией на основе утверждений приложение может явно доверять нескольким службам STS или может быть настроено на доверие к службе STS, которой доверяет та служба STS, которой оно доверяет. Это как если бы кто-то, кого вы знаете, поручился за честность того, кого вы не знаете. Это еще один пример федерации удостоверений.

Аутентификация на основе утверждений через AD FS

Многие корпоративные сети, основанные на доменах Windows Active Directory, могут воспользоваться преимуществами идентификации и проверки подлинности на основе утверждений в своих организациях с помощью служб федерации Active Directory. AD FS может служить внутренним поставщиком удостоверений и службой маркеров безопасности и/или поставщиком удостоверений федерации или службой маркеров безопасности.

Текущая версия AD FS v.2.0 поддерживает SAML, а также протоколы WS-Trust и WS-Federation. AD FS можно использовать для создания федераций с технологиями идентификации, отличными от Microsoft, такими как Oracle Identity Federation (OIF) и Shibboleth 2. AD FS взаимодействует с приложениями Windows Identity Foundation (WIF). AD FS может предоставлять единый вход (SSO) для приложений и служб, расположенных в разных сетях, удобным для пользователей способом.

Большим преимуществом AD FS является то, что он бесплатный. Его можно загрузить из Центра загрузки Microsoft и установить на Windows Server 2008 или Windows Server 2008 R2 (выпуски Standard, Enterprise, Datacenter и Foundation). AD FS 2.0 развертывается как роль сервера и управляется с помощью диспетчера серверов. Он действует как поставщик удостоверений для приложений на основе утверждений.

В сценарии проверки подлинности на основе утверждений поставщик утверждений — это программный компонент, который выдает утверждения и упаковывает их в маркеры безопасности. поставщик утверждений — это тип поставщика удостоверений. Существуют также проверяющие стороны, которыми могут быть либо приложения, полагающиеся на проверку утверждений поставщиком утверждений, либо другая промежуточная служба STS, которая проверяет утверждения, поступающие от другого поставщика, которому он доверяет.
AD FS можно настроить для работы в качестве поставщика утверждений или проверяющей стороны. Выступая в качестве поставщика утверждений, служба AD FS проверяет подлинность пользователей и выдает для них утверждения, которые передаются другим STS. Служба выдает маркеры на основе сведений об утверждениях, которые она получает из хранилища атрибутов. «Хранилище атрибутов» — это терминология Microsoft для каталога или базы данных, в которой хранятся учетные записи пользователей и их атрибуты (например, Active Directory). Эти атрибуты (например, имя пользователя, адрес электронной почты, основное имя пользователя, роль в организации, группа, к которой пользователь принадлежит и т. д.) становятся основой для утверждений, создаваемых AD FS.Обратите внимание, что, несмотря на свое название, AD FS поддерживает хранилища атрибутов, отличные от Active Directory, включая базы данных SQL Server и настраиваемые хранилища атрибутов, созданные разработчиками приложений.

Примечание:
Forefront Identity Manager (FIM) может синхронизировать информацию об утверждениях в нескольких хранилищах атрибутов.

Выступая в качестве проверяющей стороны, служба AD FS получает входящие утверждения/токены от других поставщиков (вместо получения их напрямую из хранилища атрибутов) и проверяет их, а затем передает проверенные утверждения своим собственным проверяющим сторонам. AD FS может применять правила утверждений к входящим утверждениям перед созданием исходящих утверждений на их основе. Обратите внимание, что правила утверждений не являются общими для нескольких доверительных отношений; они должны создаваться индивидуально для каждого федеративного доверительного отношения. AD FS включает шаблоны правил утверждений, чтобы администраторам было проще создавать правила.

Идентификация на основе утверждений через Windows Azure

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

Облачным приложениям обычно требуется облачный поставщик удостоверений или STS, но AD FS разработан как локальный корпоративный поставщик. Здесь на помощь приходит служба управления доступом Windows Azure AppFabric. ACS может работать с AD FS, чтобы позволить облачным приложениям принимать маркеры безопасности, выданные AD FS STS, а также те, что выданы другими локальными службами. провайдеры идентификации.

Но это еще не все — ACS также может позволить этим облачным приложениям принимать токены, выпущенные другими поставщиками облачных удостоверений, такими как Facebook, Google или собственный Windows Live ID от Microsoft. Чтобы быть поставщиком удостоверений с широкой базой, ACS поддерживает широкий спектр протоколов и форматов токенов. Он выпускает и принимает токены SAML 1.1 и 2.0. Он также поддерживает Simple Web Token (SWT), который предназначен для включения в заголовок HTTP.

Клиенты могут использовать WS-Trust и WS-Federation. Расширения WS — это стандарты безопасности, в соответствии с которыми выполняются запросы к веб-службам. WS-Trust позволяет обменивать токены безопасности на учетные данные в разных доверенных доменах. WS-Federation позволяет проверяющей стороне управлять доступом на основе достоверности утверждений, подтвержденных другой областью безопасности.

Примечание:
Настраиваемая STS, поддерживающая WS-Trust, называется Active STS; пользовательская STS, поддерживающая WS-Federation, называется пассивной STS.

ACS также может использовать OpenID 2.0 и OAuth 2.0 для запроса токенов. Это настраиваемые поставщики удостоверений, которые можно добавить в ACS. OpenID был создан сообществом открытого исходного кода, и любой может стать поставщиком OpenID. Аутентификацию OpenID используют более 50 000 веб-сайтов и более миллиарда пользователей. Сайты и службы, использующие OpenID, включают Google, Yahoo, Flickr, MySpace и WordPress.

OAuth — это открытый стандарт авторизации, который позволяет пользователю разрешать приложениям или веб-сайтам действовать от имени пользователя, не сообщая свои учетные данные. Впервые он был разработан для использования с Twitter. Таким образом, пользователь может войти в социальную сеть, а затем авторизовать веб-сайт для доступа к определенным данным, принадлежащим этому пользователю.

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

Конечно, вы можете или не можете доверять Facebook как поставщику удостоверений. В конце концов, служба на самом деле мало что делает для проверки личности пользователей, которые регистрируют учетные записи, кроме отображения условий обслуживания, которые требуют использования вашего настоящего имени, запрещают поддельные учетные записи и т. д. Хорошая новость заключается в том, что вы можно настроить ACS для приема аутентификации от тех поставщиков удостоверений, которым вы хотите доверять, и исключить тех, которым вы не доверяете. Пользователи могут выбрать, какого из доверенных поставщиков ACS они хотят использовать для аутентификации.

Идентификация на основе утверждений через Windows Live ID

У Microsoft уже есть широко распространенная реализация довольно упрощенной службы идентификации на основе утверждений в облаке: Windows Live ID. Его архитектура, основанная на утверждениях, была разработана для работы в разных границах безопасности и на разных платформах операционных систем. Вам не нужно принадлежать к домену Windows или даже использовать ОС Windows, чтобы войти в Windows Live ID.

Службы могут использовать Windows Live ID в качестве облачного поставщика удостоверений. Например, SharePoint 2010 может делегировать проверку подлинности службе Windows Live ID STS. Пользователь вводит свое имя пользователя и пароль Windows Live ID, и Windows Live ID выдает маркер утверждений SAML, который содержит уникальный идентификатор (Passport Unique Identity или PUID) и адрес электронной почты. Токен шифруется с помощью открытого ключа Windows Live ID. Сервер SharePoint преобразует токен Windows Live ID в токен SharePoint Server. Подробнее об этом можно прочитать в этой статье TechNet под названием Настройка проверки подлинности на основе утверждений с помощью Windows Live ID (SharePoint Server 2010).

Windows Live ID также можно добавить в качестве поставщика удостоверений для ACS.

Роль библиотеки удостоверений

Как видите, у Microsoft есть несколько разных поставщиков удостоверений для разных ситуаций: AD FS, служба контроля доступа Azure AppFabric, Windows Live ID. Все они используют одну и ту же библиотеку удостоверений: Windows Identity Foundation (WIF). Библиотека удостоверений — это компонент, который проверяет, имеет ли маркер безопасности действительную подпись, определяет, какой службой маркеров безопасности был выдан маркер, и проверяет, доверяет ли выдавшая STS приложение, и оценивает утверждения, содержащиеся в маркере.

WIF делает все это для токенов SAML 1.1 и 2.0 и поддерживает дополнительные протоколы. AD FS 2.0 основан на WIF. WIF — это платформа с набором API-интерфейсов, на основе которых разработчики могут создавать приложения на основе утверждений (зависящие стороны). Вот дополнительная информация о WIF.

Дальнейшее развитие аутентификации на основе утверждений

Как мы рассмотрели в предыдущих частях этой статьи, в широком смысле системы, которые мы использовали в течение многих лет для аутентификации пользователей (такие как Kerberos и NTLM), являются утверждениями, основанными на том, что имена пользователей, пароли, роли и группы членство - это формы притязаний. «Новые» платформы идентификации, основанные на утверждениях, идут намного дальше, с целью снять бремя аутентификации с «доверяющих сторон» — отдельных приложений (и их разработчиков) и возложить ее на доверенного поставщика удостоверений.

Это тоже не новая концепция; Инфраструктура открытых ключей работает таким же образом. Доверенная третья сторона (центр сертификации) проверяет учетные данные и предоставляет средства (пару открытый/закрытый ключ), на которые другие могут положиться для аутентификации личности объекта и других «утверждений».

Зачем устанавливать новый стандартизованный метод аутентификации личности? Потому что идентификация и аутентификация являются основой всей компьютерной/сетевой безопасности. Но разработчики приложений часто не являются экспертами по безопасности и могут ошибаться в этом вопросе. Преимущество системы, основанной на утверждениях, заключается в том, что при желании можно использовать различные методы аутентификации (Kerberos, смарт-карты, формы и т. д.), но системы, основанные на утверждениях, будут работать с пользователями за пределами организации (партнерские организации, клиенты и т. д.) и те, которые используют операционные системы, отличные от Windows. Между выдающими STS могут быть установлены доверительные отношения, чтобы удостоверение можно было легко объединять между областями/доменами.

Microsoft движется к модели, основанной на претензиях, уже несколько лет. Они предоставили разработчикам Windows Identity Foundation (WIF), чтобы утверждения могли использоваться приложениями ASP.NET и Windows Communication Foundation (WCF). WIF включает служебную программу FedUtil.exe, которую разработчики могут использовать для создания метаданных федерации для приложений. Они также предоставили ADFS 2.0 для создания службы маркеров безопасности (STS). SharePoint 2010 поддерживает аутентификацию на основе утверждений. Но все это было только началом. Будущие продукты Microsoft, которые в настоящее время находятся в стадии бета-тестирования, продвигаются дальше в сторону модели, основанной на заявках.

Претензии к последним и будущим продуктам Microsoft

Мы уже обсуждали, как функция динамического контроля доступа (DAC) в Windows Server 2012 построена на проверке подлинности на основе утверждений. Мы также обсудили сервер федерации Active Directory (ADFS) 2.0, который является компонентом серверной платформы Windows. Модель идентификации на основе утверждений также поддерживается другими продуктами Microsoft, взаимодействующими с компонентами Windows Server.

Идентификация на основе утверждений в Office 365

Microsoft Office 365, который обеспечивает облачный доступ к приложениям Microsoft Office, Exchange Online, SharePoint Online и Lync Online, поддерживает аутентификацию на основе утверждений с единым входом через службу федерации Active Directory (ADFS) 2.0, которую мы обсуждали в части 3. этой серии.

Пользователи должны пройти проверку подлинности для использования Office 365 (за исключением сайтов SharePoint Online, которые настроены на прием анонимных подключений). Пользователи могут использовать те же сетевые учетные данные, которые они используют для входа в свои домены Active Directory, когда синхронизация каталогов развертывается для синхронизации AD FS в корпоративной сети с Microsoft Online Services Directory.

Обратите внимание, что Office 365 поддерживает как эти федеративные удостоверения, так и облачные удостоверения (облачные идентификаторы Microsoft Online Services). Облачные удостоверения — это отдельные удостоверения с учетными данными, отличными от учетных данных пользователей в локальной службе каталогов Active Directory. Облачные удостоверения аутентифицируются с помощью традиционного метода запроса/ответа в облаке. Когда пользователи входят в систему с помощью единого входа, они проходят проверку подлинности AD FS в корпоративной сети.

Пользователи Office 365 могут пройти аутентификацию из веб-браузера (SharePoint Online, OWA и т. д.). Когда пользователь вводит свои корпоративные учетные данные на веб-странице службы входа в Office 365, браузер перенаправляется на AD FS 2.0 в корпоративной сети для проверки подлинности после обнаружения того, что пользователь принадлежит к федеративному домену. Пользователь проходит проверку подлинности через Kerberos или NTLM, а затем AD FS создает токен SAML, служба входа, в свою очередь, создает токен проверки подлинности, который предоставляется службе Office 365, к которой пользователь пытается получить доступ, и пользователь входит в службу..

Пользователи Office 365 также могут проходить аутентификацию из приложений Microsoft Office, установленных на локальном компьютере. В этом случае помощник по входу в Microsoft Online Services в Office 365 проходит через AD FS 2.0 для аутентификации учетных данных пользователя, а затем получает токен, позволяющий пользователю войти в службу.

Идентификация на основе утверждений в SharePoint

Microsoft включила модель идентификации на основе утверждений (проверка подлинности в режиме утверждений) в SharePoint 2010 для создания веб-приложений. SharePoint 2013 продвигает эту идею вперед, предоставляя SharePoint возможность аутентифицировать как пользователей систем на базе Windows, так и систем, отличных от Windows, а также делегировать удостоверение пользователя между приложениями. Вход в режиме утверждений Windows используется по умолчанию. SharePoint 2013 также поддерживает режим пассивного входа SAML, членство в ASP.NET и пассивный вход с ролью, а также вход в классический режим Windows.

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

В веб-приложениях браузер пользователя отправляет утверждения через HTTP POST. Это можно кэшировать для последующего использования. Для веб-служб утверждения находятся в заголовке безопасности конверта SOAP. Утверждения включают цифровую подпись издателя утверждений. Эмитент — это веб-приложение или служба, выпускающая токены безопасности. Windows Identity Foundation создает маркеры безопасности и шифрует их. Токены имеют формат SAML.

WIF включает службу Claims to Windows Token Service (C2TWS). Вы запускаете его вручную и должны настроить его со списком разрешенных вызывающих абонентов. C2TWS позволяет приложениям проверяющей стороны получать доступ к внешним внутренним серверам (таким как серверы SQL), получая утверждения имени участника-пользователя от маркеров безопасности, отличных от Windows, и создавая маркеры безопасности Windows, которые позволяют приложениям олицетворять пользователя. Дополнительные сведения о том, как это работает, см. в статье MSDN Идентификация и концепции на основе утверждений в SharePoint 2013.

Претензии в облаке

Облако создает новые проблемы для управления идентификацией, поскольку универсальной службы каталогов нет, поэтому старые способы (Kerberos, NTLM) не подходят для новой среды.

Очевидно, что Microsoft рассматривает модель идентификации на основе утверждений как будущее аутентификации, с DAC на основе утверждений в Server 2012 и режимом утверждений по умолчанию в SharePoint 2013. Это имеет смысл, если подумать о приверженности компании облачным вычислениям. По мере того, как все больше и больше вычислений перемещается в облако, а клиентские вычисления становятся все более разнородными с тенденцией использования собственных устройств (BYOD) на предприятиях, нам нужна модель аутентификации, которая будет работать в разных операционных системах, которые не все работают внутри домен Windows. Аутентификация на основе утверждений заполняет этот счет. Он предоставляет безопасные и очень гибкие средства для аутентификации пользователей в облачных приложениях.

Заявки не зависят от платформы. Модель проверки подлинности на основе утверждений позволяет создавать облачные приложения, которым не нужно иметь дело с процессом проверки подлинности. Он обеспечивает согласованность независимо от того, находятся ли серверы локально или в облаке, и работает практически в любой ситуации.

В облаке мы сталкиваемся с различными технологиями хостинга, а также с различными клиентскими технологиями, осуществляющими к ним доступ. Аутентификация на основе утверждений снимает бремя управления удостоверениями с ресурсов и передает его в руки объекта (поставщика удостоверений), который занимается этой задачей. Аутентификация выполняется поставщиком удостоверений, а авторизация выполняется ресурсом на основе представленных утверждений (хотя IP может принимать некоторые решения по авторизации).

Утверждения можно использовать в любой сетевой среде, но особенно они подходят для распределенных систем, а облако — это крупномасштабная распределенная система. Таким образом, по мере того, как мы неуклонно идем «в облако», решения на основе утверждений, вероятно, станут стандартом для аутентификации пользователей в доменах, организациях и сетях.