При Windows-аутентификации роли доступны автоматически и интегрированы естественным образом. В этом случае роли — на самом деле группы пользователей Windows. Вы можете использовать встроенные группы (такие как Administrator, Guest, PowerUser и так далее) или же создать свои собственные, специфичные для приложения категории (вроде Manager, Contacter, Supervisor и тому подобные). Роли не поддерживаются в аутентификации форм самой по себе, но вместе с Membership ASP.NET применяет службу ролей (Roles Service), которая представляет собой готовую к использованию реализацию поддержки и управления ролями для ваших приложений. Более того, если вы не хотите использовать эту инфраструктуру, достаточно легко создать свою собственную, которая разделит пользователей на соответствующие группы на основе их удостоверений. Подробнее об этих двух способах поддержки ролей будет рассказано далее в этой главе, в разделе "Использование службы Roles Service для авторизации, ориентированной на роли".

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

Например, следующие правила авторизации запрещают доступ анонимным пользователям, разрешая его двум конкретным пользователям (dan и matthew) и двум группам (Manager и Supervisor). Доступ всем прочим пользователям запрещен.

<authorization>
  <deny users="?" />
  <allow users="FARIAMAT\dan,FARIAMAT\matthew" />
  <allow roles="FARIAMAT\Manager,FARIAMAT\Supervisor" />
  <deny users="*" />
</authorization>

Применение правил авторизации на основе ролей концептуально просто, но может оказаться сложным на практике. Дело в том, что при использовании ролей правила авторизации могут перекрываться. Например, рассмотрим, что случится, если вы разрешите доступ группе, которая содержит определенного пользователя, а затем явно закроете доступ этому пользователю. Или наоборот — разрешив доступ пользователю по имени, закроете доступ группе, в которую он входит. В этих сценариях можно ожидать, что более тонко детализированные правила (касающиеся пользователя) получат приоритет по отношению более общих правил (касающихся групп). Или же вы можете ожидать, что более ограничивающие правила всегда будет иметь более высокий приоритет, как это принято в операционной системе Windows. Однако ни один из этих подходов не используется ASP.NET Вместо этого ASP.NET просто использует первое правило, для которого найдено соответствие. В результате решающее значение имеет порядок определения правил. Рассмотрим пример:

<authorization>
  <deny users="?" />
  <allow users="FARIAMAT\matthew" />
  <deny roles="FARIAMAT\Guest" />
  <allow roles="FARIAMAT\Manager" />
  <deny users="FARIAMAT\dan" />
  <allow roles="FARIAMAT\Supervisor" />
  <deny users="*" />
</authorization>

предыдущая    следующая страница    вначало главы    оглавление

931