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

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

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

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

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

Итак, будем исходить из следующих предпосылок в нашем сценарии:

  1. Приложение используется внутри корпоративной сети
  2. Пользователи приложения имеют учетные записи Windows
  3. Уровень компонент бизнес логики вынесен на сервер приложений, т.е. приложение построено в трехуровневой модели
  4. С системой работают только аутентифицированные пользователи и основная авторизация происходит на уровне бизнес компонент
  5. Пользовательский интерфейс может быть решен в виде GUI приложений и в виде тонкого Web клиента
  6. SQL сервер используется для хранения данных.

Протокол взаимодействия уровня пользовательского интерфейса и уровня бизнес компонент

Прежде чем перейти к рассмотрению механизмов аутентификации и авторизации, необходимо определиться с протоколами взаимодействия уровней нашей системы. При разработке с использованием .NET Framework у нас есть две основные возможности организации удаленного взаимодействия объектов - .NET Remoting и Web Services. Не останавливаясь на подробном анализе этих двух подходов, выберем SOAP в качестве протокола взаимодействия компонент бизнес-логики с уровнем пользовательского интерфейса. Естественным образом для такого сценария в качестве Сервера Приложений будет выступать Internet Information Server (IIS) в совокупности с технологиями ASP.NET, Web Services и Enterprise Services.

Такой подход позволит:

  • Использовать одни и те же интерфейсы для взаимодействия различных типов клиентов с сервером приложений
  • При необходимости использовать возможности взаимодействия по SOAP поверх HTTP при разнесении уровней приложения через Firewall
  • Обеспечить возможность интеграции сервера приложений с другими системами, в том числе и реализованными на других программных платформах
  • В дальнейшем использовать серверы интеграции приложений для увязывания различных подсистем в сложных сценариях взаимодействий

Аутентификация и авторизация

В рамках предложенного сценария система аутентификации и авторизации будет строиться на принципе использования контекста безопасности аутентифицированного пользователя Windows домена. Это позволит:
  • избежать передачи идентифицирующих данных по каналам связи в незащищенном виде
  • использовать встроенные механизмы операционной системы для проверки идентичности пользователя
  • централизовать управление правами пользователей системы
  • использовать стандартные административные средства для управления пользователями
По отношению к оригинальному, вызывающему Web Service, пользователю мы хотим осуществлять авторизацию по .NET ролям и/или по Windows ACL. В случае использования режима Windows ayтентификации в ASP.NET нет необходимости конфигурировать имперсонацию. Для проверки по .NET ролям WindowsPrincipal объект представляет контекст вызывающего, который может быть получен следующим образом:

 

WindowsPrincipal wp = (HttpContext.Current.User as WindowsPrincipal);
if ( wp.IsInRole("PowerUser") )
{
  // пользователь авторизован и включен в роль PowerUser
}

Модуль FileAuthorizationModule осуществляет проверки ACL по отношению к оригинальному вызывающему для типов файлов, которые отображены в IIS для aspnet_isapi.dll фильтра. Для статических файлов, таких как .jpg, .gif и .htm , IIS осуществляет проверку доступа, используя идентити оригинального вызывающего пользователя. Вы должны обеспечить достаточное гранулирование Windows групп в соответствие с потребностями системы безопасности. Безопасность, основанная на .NET ролях, определяет принадлежность пользователя к роли по его вхождению в Windows группу. Windows группа, используемая для управления ролями, может быть локальной для этого компьютера или группой домена.

 

Соединение с базой данных

Транзакции на однородных источниках ( в рамках одной базы данных) могут реализованы через обращение к соответствующим классам .NET Framework. При необходимости использования распределенных транзакций при взаимодействии с внешними приложениями могут быть использованы службы COM+ приложений и координатор распределенных транзакций (DTC) . В этом случае .NET компоненты должны использовать классы Enterprise Services и устанавливаться в COM+ приложения.

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

Для обеспечения такого соединения с базой данных будем использовать режим интегрированной аутентификации в SQL Server и одну учетную запись в Windows. Режим интегрированной аутентификации в SQL Server позволит избежать хранения в строке соединения учетных данных.

Примечание

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

Общая схема реализации системы безопасности

Исходя из вышесказанного, вырисовывается следующая схема построения системы безопасности для данного сценария.

 

Аутентификация

  • Пользователь аутентифицируется через вход в Windows домен (1).
  • IIS осуществляет интегрированную Windows аутентификацию (2)
  • Web Service использует Windows аутентификацию, предоставляемую ASP.NET, без имперсонации, В этом случае просто используется контекст безопасности, предоставляемый IIS аутентификацией (3)
  • Из Web Service уровень бизнес логики через вызов .NET компонент использует соединение с Базой Данных с интегрированной Windows аутентификацией (4)
  • Сервер приложений ( Web Service) осуществляет запрос к Базе Данных под единой доверительной учетной записью. Под этой же учетной записью выполняется ASPNET процесс на сервере приложений. (5)

Авторизация

  • Ресурсы в каталоге Web приложения, содержащего Web Services уровня бизнес логики, конфигурируются через Списки Управления Доступом (ACL) по отношению к пользователю, вызывающему слой бизнес логики из клиентского приложения (2)
  • Web Service осуществляет авторизацию по отношению к контексту безопасности оригинального вызывающего пользователя по .NET ролям для ограничения доступа к тем или иным методам Web Services или объектам уровня бизнес логики. В случае c Windows аутентификаций в ASP.NET Web Service .NET роли отображаются в Windows группы. (3)

Защита каналов данных

  • При необходимости можно обезопасить канал данных между клиентским приложением и сервером приложений (6) с использованием HTTPS
  • При необходимости можно обезопасить канал данных между сервером приложений и сервером баз данных (7) с использованием Internet Protocol Security (IPSec) (См. Step-by-Step Guide to Internet Protocol Security )

 

Конфигурирование подсистем безопасности

Клиентское приложение

 

Получение контекста безопасности пользователя

Пользователь осуществляет интерактивный вход в Windows домен при загрузке операционной системы. Credentials пользователя по умолчанию не передаются через прокси Web Service на стороне клиентского приложения. Для обеспечения передачи контекста безопасности на уровень сервера приложений необходимо в клиентском приложении установить соответствующий параметр для proxy объекта вызываемого Web Service, как показано ниже:

 

Proxy.Credentials = System.Net.CredentialCache.DefaultCredentials

 

Сервер приложений

IIS

 

Запретить Anonymous доступ к виртуальному каталогу Web Service

 

Установить режим интегрированной Windows аутентификации для виртуального каталога Web Service

В случае интегрированной аутентификации, IIS  может использовать или NTLM или Kerberos

ASP.NET

 

Сменить ASPNET пароль в фиксированное известное значение

Для Web приложений по умолчанию используется ASPNET учетная запись с минимумом  необходимых привилегий. По умолчанию, пароль для учетной записи управляется  ASP.NET. Поскольку требуется передача контекста безопасности этого пользователя на уровень баз данных, необходимо вручную управлять паролем для этой учетной записи. Это осуществляется следующим образом: 1. установите пароль ASPNET в фиксированное значение, используя консоль управления пользователями и группами.

2. Отредактируйте machine.config и установите атрибут пароля для элемента <processModel>:

По умолчанию:

username=”machine” password=”AutoGenerate” 

Становится:

 username=”machine” password=”фиксир._пароль

 

(machine.config расположен в директории

%windir%\Microsoft.NET\Framework\<ver>\CONFIG)

Конфигурировать Web Service для использования Windows аутентификации

Отредактируйте web.config в виртуальном каталоге Web Service. Установите элемент <authentification> :

 <authentification mode=”Windows”>

Выключить имперсонацию ASP.NET приложения

По умолчанию имперсонация выключена. Убедитесь в этом, проверив что элемент <identity> файла web.config выглядит следующим образом:

<identity impersonate=”false”>

SQL Server

Создать учетную запись Windows на SQL Server, которая совпадает с учетной записью ASPNET на сервер приложений

Должны совпадать имя  и пароль для указанной записи.

Предоставьте учетной записи следующие права:

  • Access this computer from the network
  • Deny Logon locally
  • Logon as batch job

 

Это минимальный набор прав, необходимых для доступа к SQL серверу из сети

Сконфигурируйте SQL сервер для интегрированной Windows аутентификации

 

Создайте SQL Server Login для созданной ASPNET учетной записи

Это даст серверу приложений доступ к SQL Server

Создайте пользователя в базе данных приложения и свяжите созданный на предыдущем шаге Login c этим пользователем

Это даст серверу приложений доступ к указанной базе данных

Примечания

  1. Для организации соединения с базой данных мы использовали две локальные учетные записи с одинаковыми credentials - на сервере приложений и на сервере баз данных. Управление двумя учетными записями несет дополнительную нагрузку при администрировании системы. Выходом может быть создание одной непривилегированной доменной учетной записи и использование ее на обоих серверах. Но при таком подходе придется указать имя доменного пользователя в атрибуте user . ASPNET_WP.EXE будет запускаться под этим пользователем и ему необходимо предоставить права для выполнений ASP.NET приложений.
  2. ASP.NET приложение, реализующее Web Service, запускается в нашем сценарии без имперсонации, т.е. из под непривилегированной учетной записи ASPNET с минимумом требуемых привилегий. Это понижает потенциальный ущерб при прорыве систем безопасности.
  3. При вызове из клиентского приложения методов Web Service по протоколу SOAP в случае NTLM аутентификации будем наблюдать передачу двух HTTP запросов на каждый вызов метода. Этого невозможно избежать по причине механизмов работы NTLM протокола. Это может вызывать существенные задержки при общении слоя представления данных со слоем бизнес логики. Избежать посылки двух HTTP запросов можно только при использовании Kerberos протокола. Выбор NTLM или Kerberos протокола при интегрированной аутентификации зависит от настроек конфигурации на сервере и на клиенте. В случае использования Kerberos протокола для посылки Credentials в первом запросе необходимо выставить на Proxy объекте следующие свойства:

     

    proxy.Credentials = System.Net.CredentialCache.DefaultCredentials;
    proxy.PreAuthenticate = true;
    
  4. На IIS 5.x всегда запускается один экземпляр ASPNET_WP.EXE процесса и установки для ASP.NET учетной записи конфигурируются на уровне всей машины (в machine.config). Это может быть неудобным, когда на одном IIS сервере мы хостим несколько Web приложений/Web Services c разными настройками для ASPNET пользователя. Хорошей новостью является то, что в Everett (следующая версия .NET Framework и Visual Studio.NET) и IIS6.0 данный недостаток будет ликвидирован.
  5. Мы храним пароль для ASPNET учетной записи в machine.config в открытом виде. И хотя напрямую из web приложений нет доступа к конфигурационным файлам, это является потенциальной слабостью нашей системы безопасности. В Everett будет реализована возможность использования Win32 Data Protection API (DPAPI) для работы с конфигурационными файлами на уровне ASP.NET.

Использование COM+ служб

Для доступа к другим ресурсам системы (например, факс сервер стороннего производителя, дополнительный сервис и т.п.) может потребоваться имперсонация под специализированным пользователем. Использование Logon API внутри ASP.NET приложения для имперсонации ASPNET_PW.EXE процесса под другой учетной записью является нецелесообразным, поскольку мы должны будем дать ASPNET учетной записи право "act as part of operating system", что потенциально ослабляет систему безопасности. (хорошим правилом является назначение минимума необходимых прав любому объекту в системе)

Мы можем решить, передавать или не передавать контекст пользователя до COM+ приложения. Если нам не нужно проводить дополнительной авторизации пользователя на уровне COM+ приложения, то контекст передавать не будем и обращение к COM+ приложению будет осуществляться из под ASPNET пользователя (не забывайте - мы не используем имперсонацию на уровне ASP.NET и наше ASP.NET приложение выполняется под ASPNET учетной записью).

Если мы захотим передавать контекст пользователя до COM+ приложения, то нам придется включить имперсонацию в ASP.NET приложении через изменение Web.config:

 

<identity impersonate="true">
Для передачи контекста в COM+ приложение дополнительно в machine.config в элементе <processModel> нужно установить следующий атрибут:
<processModel 
    comImpersonationLevel="Impersonate"
Не буду подробно останавливаться на конфигурировании COM+ приложения. Только сделаю замечание, что мы должны установить его как серверное приложение (т.е. будет запускаться в отдельном процессе под управлением dllhost.exe). Учетная запись, под которой будет выполняться COM+ приложение, должна быть именно той учетной записью (совпадать в случае использовании локальных записей), которая используется для доступа к удаленному ресурсу системы

Такой подход может так же быть использован, когда необходимо обеспечить доступ к различным источникам данных в SQL Server в пределах одного приложения и, соответственно, предоставлять различные Credentials для доступа к этим источникам.

 

Заключение

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

  • ресурсы, требующие защиты на уровне приложения
  • уровни приложения, на которых будет осуществляться аутентификация и авторизация пользователя
  • применяемые механизмы аутентификации и авторизации
  • использование собственных или доступных на уровне операционной системы механизмов
  • определение пользователей (объектов) по отношению, к которым работает система безопасности приложения
  • гранулированность (степень детализации) при авторизации
  • передача идентити пользователя между уровнями приложения (делегирование)
  • выполнение обращений от имени идентити (имперсонация) на разных уровнях приложения
  • взаимодействие уровня бизнес логики с внешними приложениями/службами
  • защита каналов передачи данных
Исчерпывающие ответы на вопросы, связанные безопасностью при построении ASP.NET приложений и распределенных приложений на .NET Framework, использовании Web Services и .NET Remoting, вы найдете в документе Building Secure ASP.NET Applications: Authentication, Authorization, and Secure Communication . Приготовьтесь к долгому изучению (608 страниц !!!) и разрабатывайте свои приложения с продуманной и надежной системой безопасности.


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


Автор: Дмитрий Старостин
Прочитано: 3091
Рейтинг:
Оценить: 1 2 3 4 5

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

Прислал: Антон
Это все отлично, только вот сложно все доходит. Как бы все проще это можно изучить

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

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