Управление утверждениями и авторизацией с помощью модели удостоверений

Авторизация — это процесс определения того, какие сущности имеют разрешение на изменение, просмотр или доступ к ресурсу компьютера. Например, в бизнесе только руководители могут иметь доступ к файлам своих сотрудников. Windows Communication Foundation (WCF) поддерживает два механизма обработки авторизации. Первый механизм позволяет управлять авторизацией с помощью существующих конструкций среды CLR. Второй — это модель на основе утверждений, известная как модель идентификации. WCF использует модель идентификации для формирования утверждений на основе входящих сообщений; классы модели идентификации можно расширить для поддержки новых типов утверждений в пользовательских схемах авторизации. В этом разделе представлен обзор основных концепций программирования функции модели идентификации, а также список наиболее важных классов, которые используют функции.

Сценарии модели идентификации

Следующие сценарии представляют использование модели идентификации.

Сценарий 1: Поддержка удостоверяющих данных, ролей и групповых заявок

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

Сценарий 2. Поддержка расширенных утверждений

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

Сценарий 3. Сопоставление разрозненных утверждений

Пользователь отправляет сообщение в веб-службу. Пользователь может указать свои учетные данные различными способами: сертификат X.509, маркер имени пользователя или маркер Kerberos. Веб-служба должна выполнять проверку контроля доступа таким же образом, независимо от типа учетных данных пользователя. Если с течением времени поддерживаются дополнительные типы учетных данных, система должна развиваться соответствующим образом.

Сценарий 4. Определение доступа к нескольким ресурсам

Веб-служба пытается получить доступ к нескольким ресурсам. Служба определяет, к каким защищенным ресурсам у пользователя есть доступ, сравнивая утверждения, связанные с пользователем, с утверждениями, необходимыми для доступа к ресурсу.

Термины модели идентичности

В следующем списке определены ключевые термины, используемые для описания концепций модели идентификации.

Политика авторизации
Набор правил для сопоставления набора входных утверждений с набором выходных утверждений. Оценка политики авторизации приводит к добавлению наборов утверждений в контекст оценки и последующего контекста авторизации.

Контекст авторизации
Коллекция наборов утверждений и ноль или более свойств. Результат оценки одной или нескольких политик авторизации.

Требование
Сочетание типа утверждения, права и значения.

Набор утверждений
Набор утверждений, выданных определенным издателем.

Тип утверждения
Вид утверждения. Утверждения, определенные API модели удостоверений, являются свойствами ClaimType класса. Примерами типов утверждений, предоставляемых системой, являются Dns, Email, Hash, Name, Rsa, Sid, Spn, System, Thumbprint, Uri, и X500DistinguishedName.

Контекст оценки
Контекст, в котором вычисляется политика авторизации. Содержит свойства и наборы утверждений. Становится основой контекста авторизации после завершения оценки.

Утверждение личности
Утверждение, право которого основано на идентичности.

Эмитент
Набор утверждений, содержащий по крайней мере одно удостоверяющее утверждение и который считается выдавшим другой набор утверждений.

Свойства
Набор сведений, связанных с контекстом оценки или контекстом авторизации.

Защищенный ресурс
Что-то в системе, к которому можно использовать, получить доступ или иным образом управлять, если в первую очередь выполняются определенные требования.

Правильно
Возможность над ресурсом. Права, определенные API модели удостоверений, являются свойствами Rights класса. Примерами предоставляемых системой прав являются Identity и PossessProperty.

Ценность
Что-то, по которому утверждается право.

Претензии

Модель идентификации — это система на основе утверждений. Утверждения описывают возможности, связанные с какой-либо сущностью в системе, которые часто связаны с пользователем этой системы. Набор утверждений, связанных с данной сущностью, можно рассматривать как ключ. Конкретные утверждения определяют форму этого ключа, как и физический ключ, используемый для открытия блокировки в двери. Заявления используются для получения доступа к ресурсам. Доступ к указанному защищенному ресурсу определяется путем сравнения утверждений, необходимых для доступа к данному ресурсу с утверждениями, связанными с сущностью, пытающейся получить доступ.

Утверждение — это выражение права относительно определенного значения. Правом может быть "Чтение", "Запись" или "выполнить". Значением может быть, например, база данных, файл, почтовый ящик или свойство. Утверждения также имеют тип утверждения. Сочетание типа запроса и прав предоставляет механизм для указания возможностей относительно значения. Например, утверждение типа "Файл" с правом "Чтение" по значению "Biography.doc" указывает, что сущность, с которой связано такое утверждение, имеет доступ на чтение к файлу Biography.doc. Утверждение типа "Name", с правом "PossessProperty" по значению "Martin", указывает, что сущность, с которой связано такое утверждение, обладает свойством Name со значением "Martin".

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

Утверждения о личности

Одно из конкретных прав - это право на идентичность. Утверждения, обладающие этим правом, заявляют о самобытности объекта. Например, утверждение типа "основное имя пользователя" (UPN) со значением someone@example.com и правом Identity указывает на определенное удостоверение в определенном домене.

Заявка на идентификацию системы

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

Наборы утверждений

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

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

Наборы утверждений в иерархии.

Несколько наборов претензий могут иметь одинаковый исходный набор, как показано на следующем рисунке.

Несколько наборов заявлений с одним и тем же исходным набором заявлений.

За исключением случая, когда набор утверждений является своим собственным издателем, модель идентификации не поддерживает формирование циклов для наборов утверждений. Таким образом, ситуация, когда набор утверждений A выдан набором утверждений B, который сам выдан набором утверждений A, никогда не может возникнуть. Кроме того, модель идентификации личности не поддерживает наборы утверждений с разными издателями. Если два или более издателей должны выдавать заданный набор утверждений, необходимо использовать несколько наборов утверждений, каждый из которых содержит одинаковые утверждения, но имеющие разные издатели.

Происхождение утверждений

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

Политики авторизации

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

Например, политика авторизации имеет доступ к базе данных, которая включает даты рождения различных сущностей, использующих систему. Политика авторизации использует эти сведения для добавления утверждения "Over18" в контекст. Обратите внимание, что это утверждение Over18 не раскрывает никаких сведений о субъекте, кроме факта, что он старше 18 лет. Обратите внимание, что интерпретация утверждения Over18 зависит от понимания семантики этого утверждения. Политика авторизации, которая добавила утверждение, понимает эти семантики на определенном уровне. Код, который впоследствии проверяет утверждения, полученные от оценки политики, также должен быть информирован о соответствующих семантиках.

Для данной политики авторизации может быть нужно многократная оценка, так как по мере добавления утверждений другими политиками авторизации, данная политика авторизации может добавить еще больше утверждений. Идентификационная модель предназначена для продолжения оценки до тех пор, пока больше утверждения не добавляются в контекст действующими политиками авторизации. Эта продолжаемая оценка политик авторизации препятствует применению какого-либо определенного порядка оценки в отношении политик авторизации; их можно оценить в любом порядке. Например, если политика X добавляет только утверждение Z, если политика A добавила утверждение B, то если X вычисляется первым, он изначально не добавляет утверждения Z. Впоследствии A вычисляется и добавляет утверждение B. X затем вычисляется во второй раз, и на этот раз он добавляет утверждение Z.

У данной системы может быть много политик авторизации.

Компьютер Key-Making

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

Контекст авторизации

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

Замки

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

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

Управление утверждениями и авторизацией

WCF и модель удостоверений

WCF использует инфраструктуру модели удостоверений в качестве основы для выполнения авторизации. В WCF ServiceAuthorizationBehavior класс позволяет указывать политики авторизации в рамках службы. Такие политики авторизации называются внешними политиками авторизации, и они могут выполнять обработку утверждений на основе локальной политики или взаимодействия с удаленной службой. Диспетчер авторизации, представленный классом ServiceAuthorizationManager , оценивает внешние политики авторизации вместе с политиками авторизации, которые распознают различные типы учетных данных (маркеры) и заполняет контекст авторизации утверждениями, соответствующими входящего сообщения. Контекст авторизации представлен классом AuthorizationContext .

Программирование модели идентификации

В следующей таблице описывается объектная модель, используемая для программных расширений модели удостоверений. Все эти классы существуют либо в пространстве имен System.IdentityModel.Policy, либо в пространстве имен System.IdentityModel.Claims.

Класс	Описание
Компонент авторизации	Класс модели идентификации, реализующий интерфейс IAuthorizationComponent.
IAuthorizationComponent	Интерфейс, предоставляющий одно строковое свойство только для чтения: id. Значение этого свойства уникально для каждого экземпляра в системе, реализующей этот интерфейс.
AuthorizationContext	Компонент авторизации, содержащий набор экземпляров `ClaimSet` с нулевыми или несколькими свойствами; результат оценки одной или нескольких политик авторизации.
Claim	Сочетание типа требования, права и значения. Части и значения ограничены типом утверждения.
ClaimSet	Абстрактный базовый класс. Коллекция `Claim` экземпляров.
DefaultClaimSet	Запечатанный класс. Реализация `ClaimSet` класса.
EvaluationContext	Абстрактный базовый класс. Передается политике авторизации во время оценки политики.
IAuthorizationPolicy	Интерфейс, производный от `IAuthorizationComponent` и реализованный классами политики авторизации.
Rights	Статический класс, содержащий предопределенные правильные значения.

Следующие классы также используются для программирования модели удостоверений, но не находятся в пространствах имен, таких как System.IdentityModel.Policy или System.IdentityModel.Claims.

Класс	Описание
ServiceAuthorizationManager	Класс, предоставляющий метод, CheckAccessCore, для выполнения проверок авторизации на основе заявлений для каждой операции в сервисе. Вам необходимо создать производный класс и переопределить метод.
ServiceAuthorizationBehavior	Запечатанный класс, предоставляющий различные свойства, связанные с поведением службы в отношении авторизации.
ServiceSecurityContext	Класс, обеспечивающий контекст безопасности, включая контекст авторизации, для текущей или готовящейся к выполнению операции. Экземпляр этого класса является частью OperationContext.

Значительные члены

Следующие члены обычно используются для создания новых типов утверждений.

Член	Описание
CheckAccessCore	Производные классы реализуют этот метод для проведения проверок доступа на основе заявок перед выполнением операций в службе. Все и любые сведения в предоставленном OperationContext, или в другом месте, могут быть рассмотрены при принятии решения о проверке доступа. Если CheckAccessCore возвращает `true`, то доступ предоставляется и операция может выполняться. Если `CheckAccessCore` возвращается `false`, то доступ запрещен и операция не выполняется. Пример см. в статье "Практическое руководство. Создание пользовательского диспетчера авторизации для службы".
ServiceAuthorizationManager	Возвращает ServiceAuthorizationManager для службы. ServiceAuthorizationManager отвечает за принятие решений об авторизации.
ExternalAuthorizationPolicies	Коллекция пользовательских политик авторизации, указанных для службы. Эти политики оцениваются в дополнение к этим политикам, связанным с учетными данными в входящих сообщениях.

См. также

Last updated on 2025-06-17