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

В Web-приложениях разные типы авторизации происходят на разных уровнях. Например, на самом верхнем уровне ваш код может проверять личность пользователя и решать, можно ли продолжать данную операцию. На нижнем уровне можно настроить ASP.NET так, чтобы запрещать доступ к определенным Web-страницам или каталогам для определенных пользователей или ролей. На еще более низком уровне, когда ваш код выполняет различные задачи — такие как подключение к базе данных, открытие файла запись в протокол событий и тому подобное — операционная система Windows проверяет права учетной записи Windows, от имени которой исполняется данный код. В большинстве ситуаций вы не захотите полагаться на этот самый нижний уровень, поскольку ваш код всегда будет выполняться от имени фиксированной учетной записи. В IIS 5.x эта учетная запись называется ASPNET. В IIS 6.0 — это фиксированная учетная запись NetWork Service (в обоих случаях вы можете переопределить учетную запись по умолчанию, как описано в главе 18).

Существует несколько причин применения предопределенной учетной записи для запуска кода ASP.NET. Почти во всех приложениях права, выданные пользователю, не соответствуют правам, которые требуются приложению, работающему от имени пользователя. Как правило, ваш код нуждается в более широком наборе привилегий, чтобы выполнять задачу идентификации, и вы не захотите выдавать такие права каждому пользователю, который может обращаться к вашему приложению, Например, вашему коду может понадобиться создавать протокольные записи о возможных сбоях, даже если данному пользователю не разрешено напрямую писать в протокол событий Windows, в файл или в базу данных. Аналогично приложения ASP.NET всегда должны иметь право доступа в каталог C:\[WinDir]\Microsoft.NET\[Version]\Tempоrary ASP.NET Files, чтобы создавать и кэшировать двоичные версии ваших Web-страниц. И, наконец, вы можете пожелать использовать систему аутентификации, которая вообще, никак не взаимодействует с Windows. Например, приложения электронной коммерции могут проверять адреса электронной почты пользователей по базе данных серверной стороны. В этом случае личность пользователя никак не соответствует пользовательской учетной записи Windows.

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

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

807