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

  • Статья

Авторизация - это процесс определения сущностей, имеющих право изменять, просматривать компьютерный ресурс или получать доступ к нему. Например, в организации только менеджерам может быть разрешен доступ к файлам их сотрудников. 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.

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

Идентификационное утверждение
Утверждение, правом которого является удостоверение.

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

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

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

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

Значение
Некоторое значение, в отношении которого утверждается право.

Претензии

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

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

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

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

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

Идентификационное утверждение "система"

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

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

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

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

Sets of claims within the hierarchy.

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

Multiple sets of claims with the same issuing claim set.

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

Источники утверждений

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

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

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

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

Заданная политика авторизации может требовать, чтобы она оценивалась несколько раз, поскольку, так как другие политики авторизации добавляют утверждения, эта политика авторизации может добавить еще больше утверждений. Модель удостоверения разработана для продолжения оценки до тех пор, пока в контекст больше не будет добавляться никаких утверждений любой из действующих политик авторизации. Такая продолжающаяся оценка политик авторизации исключает необходимость принудительного установления конкретного порядка оценки политик авторизации; они могут оцениваться в любом порядке. Например, если политика X добавляет утверждение Z, только если политика A добавила утверждение B, то если сначала оценивается политика X, она изначально не добавляет утверждение Z. Затем оценивается политика A и она добавляет утверждение B. После этого второй раз оценивается политика X и теперь она добавляет утверждение Z.

Заданная система может иметь много действующих политик авторизации.

Компьютер, создающий ключи

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

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

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

Блокировки

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

Резюме

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

Managing claims and authorization

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

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

Программирование модели удостоверения

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

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

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

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

Важные члены

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

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

См. также