Исходники.Ру - Программирование
Исходники
Статьи
Книги и учебники
Скрипты
Новости RSS
Магазин программиста

Главная » Статьи по программированию » .NET - ASP.NET »

Обсудить на форуме Обсудить на форуме

Модель безопасности ASP.NET
Решение вопросов безопасности в распределенных многоуровневых приложениях представляет собой непростую задачу. Чтобы правильно ее решать необходимо четко представлять механизмы безопасности, лежащие в основе той или иной используемой технологии...
Решение вопросов безопасности в распределенных многоуровневых приложениях представляет собой непростую задачу. Чтобы правильно ее решать необходимо четко представлять механизмы безопасности, лежащие в основе той или иной используемой технологии. Частота возникающих вопросов связанных с безопасностью Web приложений на основе ASP.NET натолкнуло меня на мысль, что не всегда есть четкое понимание общей архитектуры безопасности ASP.NET приложений. Зачастую, отвечая на вопросы, и сам ловил себя на мысли, что мои ответы выглядят фрагментарно и , более того , при отсутствии полной информации по той или иной ситуации, могут уводить от правильного решения проблемы. Важность этой темы обуславливается так же и тем, что ASP.NET используется как основная технология для построения Web Services на платформе .NET и может использоваться для оганизации взаимодействии компонент по HTTP каналу в .NET Remoting. Таким образом понимание архитектуры безопасности ASP.NET становится критически важным при построении распределенных приложений на .NET. Вместе с тем, эта архитектура претерпела существенные изменения по сравнению со своей предшественницей – технологией безопасности ASP. Зачастую именно здесь и кроется корень проблем разработчиков, пытающихся напрямую применить к ASP.NET подходы безопасности, применяемые ими в ASP. Кроме того и .NET Framework привнесла новые механизмы, которые могут использоваться внутри ASP.NET приложений. Вместе с тем сведения, относящееся к этой важной теме, разбросаны по документации, фрагментированы и порой из них трудно составить общую картину архитектуры безопасности ASP.NET. В Microsoft работают на созданием целого ряда руководств по использованию технологий .NET в распределенных многоуровневых приложений. Значительная часть этих документов будет посвящена вопросам безопасности. Данный материал можно рассматривать как сжатое изложение части вопросов, связанных с архитектурой безопасности ASP.NET.

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

Прежде всего давайте определим термины. (Вы можете пропустить этот абзац, если имеет представление о предмете обсуждения)

Аутентификация – процесс идентификации, определения подлинности того или иного объекта, сущности в системе (интерактивного пользователя, процесса системной службы и т.п.). Например, это может быть сопоставление имени пользователя с его паролем.
Идентити – аутентифицированный объект в системе.
Авторизация – процесс определения прав доступа аутентифицированной сущности – identity.
Принципал – это аутентифицированная сущность с наборами прав к объектам в системе.
 

Различные технологии, используемые при построении многоуровневых приложений, предлагают различные механизмы аутентификации и авторизации. В этой статье мы не будем останавливаться на них подробно (это просто невозможно в рамках небольшого материала), а скорее посмотрим как они соотносятся друг с другом. .NET добавила новый слой со своими механизмами безопасности. Это прежде всего безопасноть на уровне доступа кода, кода код как таковой выступает идентити (аутентифицируемая сущность), по отношению к которому определяются права на выполнение операций. При этом после того, как Common Language Runtime проверил и предоставил доступ на выполнение операций выполняемому приложению (коду), независимую проверку осуществляет операционная система ( и используемые серверы), но уже по отношению к идентити пользователя (учетной записи), под которой выполняется процесс приложения. Наборы разрешений соотносятся с кодом (на основе предоставляемым кодом свидетельства – цифровая подпись, зона загрузки, имя публикатора и т.п.) в политиках безопасности. Именно на основе этих политик CLR принимает решение о доступе кода на выполнение операций. Тема безопасности на уровне кода заслуживает отдельного внимания и будет рассмотрена в последующих статьях.


рис 1. Типы авторизации

ASP.NET работает совместно с IIS, .NET Framework и нижележащими сервисами операционной системы, обеспечивающими целый ряд механизмов аутентификации и авторизации. Давайте проследим последовательность событий аутентификации и авторизации при обработке web запроса к ASP.NET приложению.
рис. 2 Архитектура безопасности ASP.NET

1. HTTP запрос приходит из сети. Secure Sockets Layout (SSL) может быть использован для идентификации Web сервера, т.е. для подтверждения тождественности Web сервера искомому URL. Это достигается через применение серверных сертификатов. Дополнительно (но не обязательно) SSL может применяться и для идентификации клиента (через применение клиентских сертификатов). SSL обеспечивает безопасный (шифрованный) канал передачи сообщений между клиентом (Internet browser) и сервером (Web Server)

2. IIS аутентифицирует вызывающего с использованием Basic, Digest, Integrated (NTLM или Kerberos) или Certificate механизмов - как это было сконфигурировано для виртуального каталога Web приложения. IIS создает маркер доступа Windows для каждого аутентифицированного пользователя. Если сайт (на уровне IIS) не требует аутентификации, то можно выбрать опцию Anonymous аутентификации и в этом случае на все запросы маркер доступа будет создан для Internet User Account - IUSR_MACHINE по умолчанию

3. IIS авторизует вызывающего на доступ к требуемому ресурсу. При авторизации доступа используются списки управления (ACL) доступа NTFS, присоединенные к требуемому ресурсу. Дополнительно IIS может быть сконфигурирован для принятия запросов приходящих только от выделенных IP адресов.

4. IIS передает маркер доступа Windows для аутентифицированного пользователя к ASP.NET (это может быть маркер доступа Internet User, если был выбран Anonymous механизм аутентификации). Собственно с этого момента и начинаются различия обработки запроса в технологиях ASP и ASP.NET. Как Вы знаете, isapi фильтр ASP, выполняющийся в процессе IIS (inetinfo.exe) имперсонировал пользователя на основании полученного маркера доступа Windows и вся авторизация на запрашиваемые уже из кода ASP страниц ресурсы производилась по отношению к аутентифицированному пользователю. ASP.NET isapi фильтр передает маркер доступа Windows отдельному процессу ASP.NET (aspnet_wp.exe), запущенному под выделенной учетной записью пользователя – ASPNET (учетную запись ASPNET процесса можно конфигурировать через web.config).

5. ASP.NET аутентифицирует вызывающего. Аутентификация ASP.NET может быть сконфигурирована одним из следующих вариантов:

  • Windows
    В этом случае ASP.NET не производит дополнительной аутентификации и принимает маркер доступа Windows от IIS.
  • Forms
    В этом случае credentials, предоставляемые вызывающим (через HTML форму) используются для аутентификации в соответствии с запрограмированным механизмом . При этом для хранения имен пользователей и паролей (лучше зашифрованных), как правило, используют SQL базу данных или Active Directory.
  • Passport
    В этом случае пользователь перенаправляется на сервер Passport и служба аутентификации Microsoft Passport аутентифицирует пользователя.
Примечание. В случае конфигурирования ASP.NET для Forms или Passport аутентификации в IIS аутентификация для виртуального каталога приложения должна быть сконфигурирована как Anonymous.

6. ASP.NET авторизует доступ к требуемому ресурсу или операции.

  • Модуль авторизации по URL - UrlAuthorizationModule (системный HTTP модуль) использует авторизационные правила из web.config (указанные в элементе) для проверки прав доступа вызывающего к запрашиваемому файлу или директории.
  • Другой модуль Windows аутентификации - FileAuthorizationModule (так же системный HTTP модуль) проверяет полномочия вызывающего на доступ к требуемому ресурсу. Этот модуль задействуется только в случае конфигурирования Windows аутентификации для ASP.NET приложения. Полученный от IIS маркер доступа Windows проверяется с ACL который защищает ресурс.
  • Роли .NET так же могут быть использованы (или декларативно или программно) для обеспечения вызывающему необходимого доступа к запрашиваемому ресурсу или операции.
7. Код Вашего приложения обращается к тем или иным локальным и удаленным ресурсам под правами конкретного пользователя (учетной записи Windows). По умолчанию, ASP.NET не подменяет(имперсонирует) пользователя и следовательно, выполняется под выделенной ASPNET учетной записью. Альтернативными опциями являются имперсонирование вызывающего пользователя (аутентифицированного IIS пользователя Windows) или конфигурирование выделенной учетной записи.

Таким точками авторизации пользователя в ASP.NET приложении являются:

  • IIS
    При выключенной Anonymous аутентификации IIS разрешает доступ только пользователям, которых он может аутентифицировать в собственном домене или в доверяемом домене. Для статических файлов (файлы, для которых нет соответствия в ISAPI расширении – например, .jpg, .gif, .htm) IIS использует NTFS разрешения, ассоциированные с запрашиваемым файлом.
  • ASP.NET
     
    • UrlAuthorizationModule
      Вы можете сконфигурировать эелемент в web.config и управлять через него какие пользователи и группы имеют доступ к приложению. Можно конфигурировать на уровне отдельных файлов или целиком приложения. Авторизация основывается на IPrincipal объекте, который хранится в свойстве HttpContext.Current.User . Таким образом, авторизация на основе сопоставления имен пользователей и url запрашиваемых ресурсов работает для все типов аутентификации ASP.NET (т.е. не только для Windows, но и для Forms и для Pasport)
      Примечание. Правила записи имен пользователей и групп могут зависеть от выбранной схемы аутентификации.
    • FileAuthorizationModule
      Для файлов, для которых существует соответствие в конфигурации IIS для ASP.NET ISAPI расширения (aspnet_isapi.dll), автоматически осуществляется проверка доступа по отношению к маркеру доступа WIndows (который может быть маркером доступа IUSR_MACHINE)
      Примечание. Имперсонация пользователя не требуется для работы FileAuthorizationModule.
      FileAuthorizationModule класс осуществляет проверки только для запрашиваемого в процессе web запроса файла. Он не проверяет доступ к файлам, к которым обращение происходит из кода ASPX страницы (или вызываемых из нее компонент). Например, Вы в коде ASPX страницы обращаетесь к gif файлу. В ACL к ASPX странице Вы запрещаете доступ определенному прользователю и gif файл не может быть получен через обращение к ASPX странице этим пользователем. Но при обращении к Gif файл напрямую через web запрос проверка будет осуществляться только IIS и если доступ к gif файлу разрешен, запрос будет обработан успешно.
    • Запросы на доступ для Principal и явные проверки на принадлежность ролям. Этот механизм обеспечивает система безопасности доступа кода – Code Access Security (CAS). Вы можете использовать запросы доступ для Principal в коде декларативно и программно как дополнителный авторизационный механизм. Проверки на доступ для Principal позволяют Вам контролировать доступ к классам, методам или индивидуальным фрагментам кода на основе идентификациии пользователя и принадлежности его к группам, что определяется IPrincipal объектом, присоединенным к текущей нити процесса.

      Примечание. Проверки на доступ для Principal приводят к генерации исключения в случае запрещения доступа. Этим обработка таких проверок отличается от IPrincipal.IsInRole метода, просто возвращающего булево значение.

      При Windows аутентификации ASP.NET автоматически присоединяет WindowsPrincipal объект, который представляет аутентифицированного пользователя, к текущему web запросу (в свойтсве HttpContext.User). При Forms и Passport аутентификации создается GenericPrincipal объект с соответствующим идентифицированным пользователем (без ролей – они должны быть добавлены Вашим кодом в событии AuthenticateRequest объекта Application) и записывается в HttpContext.User .

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


Может пригодится:


Автор: dmitrys
Прочитано: 4792
Рейтинг:
Оценить: 1 2 3 4 5

Комментарии: (0)

Добавить комментарий
Ваше имя*:
Ваш email:
URL Вашего сайта:
Ваш комментарий*:
Код безопастности*:

Рассылка новостей
Рейтинги
© 2007, Программирование Исходники.Ру