Поделиться через

Механизмы управления доступом

  • Статья

Доступ можно управлять несколькими способами с помощью Windows Communication Foundation (WCF). В настоящем разделе кратко описываются различные механизмы и приводятся рассуждения о том, когда и какой способ использовать; раздел должен помочь пользователю выбрать правильный механизм использования. Технологии доступа перечислены в порядке сложности. Самым простым является PrincipalPermissionAttribute; самым сложным - модель удостоверения.

Помимо этих механизмов, олицетворение и делегирование с WCF объясняется в разделе "Делегирование и олицетворение".

PrincipalPermissionAttribute

Для ограничения доступа к методу службы используется PrincipalPermissionAttribute. Если атрибут применяется к методу, его можно использовать для запроса удостоверения или членства конкретного вызывающего объекта в группе Windows или ASP.NET роли. Если подлинность клиента проверена при помощи сертификата X.509, клиенту дается первичное удостоверение, состоящее из имени субъекта и отпечатка сертификата.

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

Дополнительные сведения об использовании атрибута см. в разделе "Практическое руководство. Ограничение доступа с помощью класса PrincipalPermissionAttribute". Дополнительные сведения об удостоверениях см. в разделе "Удостоверение службы" и "Проверка подлинности".

Поставщик участия ASP.NET

Функция ASP.NET является поставщиком членства. Даже если поставщик членства технически не является механизмом контроля доступа, он позволяет контролировать доступ к службе путем ограничения набора возможных удостоверений, которые могут получить доступ к конечной точке службы. Возможность членства включает в себя базу данных, которая может быть заполнена комбинациями имени/пароля, что позволяет пользователям веб-сайта создавать учетные записи на сайте. Чтобы получить доступ к службе, использующую поставщика членства, пользователь должен войти с помощью имени пользователя и пароля.

Примечание.

Сначала необходимо заполнить базу данных с помощью функции ASP.NET, прежде чем служба WCF сможет использовать ее для авторизации.

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

Дополнительные сведения об использовании функции членства в службе WCF см. в статье "Практическое руководство. Использование поставщика членства ASP.NET".

Поставщик ролей ASP.NET

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

Вы также можете использовать поставщик ролей ASP.NET, если у вас есть база данных поставщика ролей ASP.NET и хотите использовать тот же набор правил и назначений пользователей в службе WCF.

Дополнительные сведения об использовании функции поставщика ролей см. в статье "Практическое руководство. Использование поставщика ролей ASP.NET с помощью службы".

Диспетчер авторизации

Другая функция объединяет диспетчер авторизации (AzMan) с поставщиком ролей ASP.NET для авторизации клиентов. Когда ASP.NET размещает веб-службу, AzMan можно интегрировать в приложение, чтобы авторизация в службе выполнялось через AzMan. ASP.NET диспетчер ролей предоставляет API, позволяющий управлять ролями приложений, добавлять и удалять пользователей из ролей, а также проверка членство в ролях, но не позволяет запрашивать, может ли пользователь выполнять именованную задачу или операцию. AzMan позволяет определять отдельные операции и комбинировать их в задачах. При помощи AZMan кроме проверок роли можно также проверять, может ли пользователь выполнять задачу. Назначение роли и авторизация задачи могут быть настроены вне приложения или выполнены программно внутри приложения. Оснастка администрирования AzMan консоли управления MMC позволяет администраторам менять задачи, которые может выполнять определенная роль во время выполнения и управлять членством ролей каждого пользователя.

Вы также можете использовать AzMan и поставщик ролей ASP.NET, если у вас уже есть доступ к существующей установке AzMan и хотите авторизовать пользователей службы с помощью функций сочетания поставщика AzMan/role.

Дополнительные сведения об AzMan и поставщике ролей ASP.NET см. в статье "Практическое руководство. Использование диспетчера авторизации (AzMan) с ASP.NET 2.0. Дополнительные сведения об использовании AzMan и поставщике ролей для служб WCF см. в статье "Практическое руководство. Использование поставщика ролей диспетчера авторизации ASP.NET с помощью службы".

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

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

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

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

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

См. также