Авторизация и роли в IIS 8

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

На рисунке ниже показано средство конфигурирования авторизации консоли управления IIS 8. В этом разделе мы углубимся в некоторые детали механизмов конфигурирования IIS 8.

Средство URL-авторизации IIS 8 работает совершенно независимо от ASP.NET, оно реализовано в отдельном встроенном HTTP-модуле, поставляемом с IIS 8. Как упоминалось ранее, он конфигурируется в отдельном разделе внутри файла web.config. Любое правило авторизации, которое настраивается через консоль управления IIS 8, добавляется в раздел внутри раздела файла web.config. Типичная конфигурация авторизации IIS 8 в файле web.config выглядит подобно приведенной ниже и концептуально работает точно так же, как правила авторизации ASP.NET:

Конфигурация внутри этого раздела подчиняется тем же правилам, что и конфигурация авторизации ASP.NET. IIS 8 обрабатывает эти правила сверху вниз, и как только находит соответствующее правило, немедленно останавливается. Опять-таки, не забудьте, что авторизация реализована в отдельном встроенном модуле UrlAuthorizationModule.dll, который поставляется вместе с IIS 8:

Почему важно понимать разницу? Прежде всего, UrlAuthorizationModule.dll можно использовать из IIS 8 независимо от ASP.NET. Когда веб-сервер IIS 8 установлен на машине, a ASP.NET — нет, URL-авторизацию по-прежнему можно использовать через встроенный модуль.

Однако вторая причина намного важнее для разработчика ASP.NET. Встроенный модуль URL-авторизации, поставляемый в составе IIS 8, способен корректно идентифицировать зарегистрированных пользователей, аутентифицированных всеми возможными модулями аутентификации, включая базовую аутентификацию, Windows-аутентификацию и даже аутентификацию с помощью форм. Это связано с тем, что модуль разработан таким образом, что он понимает билет аутентификации с помощью форм (закодированный либо в cookie-наборе, либо в строке запроса). Но, к сожалению, он не был реализован с учетом ролей ASP.NET.

Какова причина этого? Роли извлекаются инфраструктурой ASP.NET из хранилища на определенной стадии внутри жизненного цикла приложения (например, из базы данных, сконфигурированной для поставщика ролей). Информация о ролях затем инкапсулируется в управляемых объектах, реализующих интерфейс IPrincipal, и потому хранится в чистых управляемых объектах .NET, которые не доступны встроенным модулям IIS 8. Поэтому такие встроенные модули IIS 8, как UrlAuthorizationModule, не могут использовать эту информацию.

Как упоминалось ранее, в случае имен пользователей можно полностью полагаться на управление авторизацией IIS 8. Причина в том, что встроенный модуль реализован так, что он распознает пользователей, аутентифицированных встроенными модулями, и пользователей, аутентифицированных управляемыми модулями, такими как FormsAuthenticationModule. Чтобы использовать модуль FormsAuthenticationModule в сочетании с встроенным UrlAuthorizationModule, модуль FormsAuthentication должен быть разрешен для встроенной очереди обработки.

И, наконец, это означает, что авторизация на основе ролей является одним из нескольких исключений, где конфигурация IIS и ASP.NET все еще должна учитываться раздельно.

Авторизация с помощью ролей ASP.NET в IIS 8

Теперь известно, что встроенный модуль URL-авторизации, поставляемый с IIS 8, не понимает специфичной для ASP.NET информации о ролях, поскольку эта информация инкапсулирована в управляемых объектах, которые реализуют управляемые интерфейсы. С другой стороны, запуск IIS 8 в интегрированном режиме ASP.NET предоставляет унифицированный конвейер обработки HTTP, где встроенные и управляемые модули обрабатываются внутри одного конвейера HTTP-модулей. Поэтому для расширения поведения по умолчанию IIS 8 можно использовать любой управляемый HTTP-модуль, написанный на языке .NET по вашему выбору.

Это означает, что вы можете писать собственные HTTP-модули с помощью .NET и интегрировать их в конвейер обработки IIS 8. Но это также означает возможность интеграции существующих модулей ASP.NET, таких как FormsAuthentication или даже UrlAuthorization, непосредственно в конвейер обработки. Это позволит достичь следующих двух целей намного легче, чем в предыдущих версиях IIS:

защитить ресурсы ASP.NET;

использовать средства безопасности ASP.NET для любого веб-приложения, даже написанного не на ASP.NET.

Обе цели достигаются одинаковым способом — нужно просто разрешить управляемому модулю UrlAuthorization из ASP.NET работать в конвейере вместе с другими модулями IIS 8 (и модулями ASP.NET).

Эту опцию конфигурации можно включить с помощью средства конфигурирования модулей IIS 8, как показано на рисунке ниже:

Источник

Настройка аутентификации Windows при расположении веб-сервера IIS и рабочих серверов на разных машинах

Описание проблемы

Не работает аутентификация операционной системы (windows) через IIS при использовании тонкого клиента или веб-клиента.

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

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

Решение проблемы

На сервере 1С включить технологический журнал, используя следующую настройку:

Воспроизвести ситуацию с неудачной аутентификацией операционной системы. Авторизоваться под пользователем операционной системы, указанным в свойствах пользователя 1С.

Открыть технологический журнал рабочего процесса и найти событие EXCP со следующим описанием: «Идентификация пользователя не выполнена
Неправильное имя или пароль пользователя»

Обратите внимание на предшествующее ему событие CONN и значение свойства DstUserName2 — именно в таком виде пользователь должен быть указан в свойствах пользователя информационной базы.

04:45.940011-0,CONN,2,process=rphost,t:clientID=60,Txt=Srvr: SrcUserName1: svc-1c@DOMAIN701.COM
04:45.940012-0,CONN,2,process=rphost,t:clientID=60,Txt=Srvr: DstUserName1: testuser2@DOMAIN701.COM(DOMAIN701.COM\testuser2)
04:45.971001-0,CONN,2,process=rphost,t:clientID=60,Txt=Srvr: DstUserName2: DOMAIN701\testuser2(DOMAIN701\testuser2)
04:46.205021-0,EXCP,2,process=rphost,p:processName=trade,t:clientID=60,t:applicationName=WebServerExtension,t:computerName=webserver,t:connectID=19,Exception=a01f465c-ed70-442e-ada5-847668d7a41c,Descr=’src\VResourceInfoBaseServerImpl.cpp(991):
a01f465c-ed70-442e-ada5-847668d7a41c: Идентификация пользователя не выполнена
Неправильное имя или пароль пользователя’

Заменить значение свойства «Пользователь» пользователя информационной базы согласно следующему формату «\\» + [Имя пользователя из свойства DstUserName2 без скобок].

Проверить работоспособность аутентификации средствами операционной системы, войдя в информационную базу, используя веб-клиент.

Расположение веб-сервера IIS и рабочих серверов 1С на разных машинах

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

56:39.487001-0,CONN,2,process=rphost,p:processName=accounting,t:clientID=39,t:applicationName=WebServerExtension,t:computerName=webserver,t:connectID=16,Txt=Srvr: SrcUserName1: winserver1c$@DOMAIN701.COM
56:39.487002-0,CONN,2,process=rphost,p:processName=accounting,t:clientID=39,t:applicationName=WebServerExtension,t:computerName=webserver,t:connectID=16,Txt=Srvr: DstUserName1: testuser2@DOMAIN701.COM(DOMAIN701.COM\testuser2)
56:39.596004-0,CONN,2,process=rphost,p:processName=accounting,t:clientID=39,t:applicationName=WebServerExtension,t:computerName=webserver,t:connectID=16,Txt=Srvr: DstUserName2: NT AUTHORITY\ANONYMOUS LOGON(NT AUTHORITY\ANONYMOUS LOGON )
56:39.659003-0,EXCP,2,process=rphost,p:processName=accounting,t:clientID=39,t:applicationName=WebServerExtension,t:computerName=webserver,t:connectID=16,Exception=a01f465c-ed70-442e-ada5-847668d7a41c,Descr=’src\VResourceInfoBaseServerImpl.cpp(991):
a01f465c-ed70-442e-ada5-847668d7a41c: Идентификация пользователя не выполнена
Неправильное имя или пароль пользователя’

При возникновении такой ситуации необходимо проверить следующие настройки:

1) Убедиться, что процессы сервера 1С запущены от имени доменной учетной записи, входящей в группу Domain Users.

2) Убедиться, что веб-сервер IIS настроен корректно.

В публикации информационной базы найти настройки аутентификации

В настройках аутентификации отключить анонимную аутентификацию и включить Windows-аутентификацию. В Windows-аутентификации упорядочить доступных провайдеров так, чтобы на первом месте был Negotiate.

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

После изменения настроек перезапустить веб-сервер с помощью команды iisreset в командной строке.

3) Убедиться, что в контроллере домена в свойствах компьютера, на котором запущен веб-сервер, на вкладке делегирование установлено «Доверять компьютеру делегирование любых служб (только Kerberos)»

Для этого откройте оснастку Active Directory Users and Computers (dsa.msc), в компьютерах найдите веб-сервер, перейдите в его свойства и на вкладке Делегирование установить значение «Доверять компьютеру делегирование любых служб (только Kerberos)» и нажать применить.

4) Убедиться, что на клиенте в свойствах обозревателя разрешена встроенная проверка подлинности Windows.

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

Важно: аутентификации Windows при расположении веб-сервера IIS и рабочих серверов на разных машинах в тонком клиенте работает, начиная с версии 8.3.10.2620 (для тестирования).

Источник

Настройка аутентификации в IIS 8

IIS 8 поддерживает интегрированный режим ASP.NET, который помимо прочего объединяет конвейер обработки ASP.NET HTTP с конвейером обработки IIS HTTP. Это предоставляет в распоряжение богатейший набор новых возможностей, которые можно использовать в сочетании с имеющимися знаниями ASP.NET. Например, одна из них — это возможность применения аутентификации с помощью форм ASP.NET для других веб-приложений, сконфигурированных в IIS 8, которые не обязательно должны быть построены на ASP.NET.

Более того, IIS 8 использует файл web.config для хранения многих частей конфигурации веб-приложений внутри веб-сервера. Это означает возможность настройки многих параметров приложения с использованием либо консоли управления IIS 8, либо за счет непосредственной модификации файла web.config. Благодаря тесной интеграции средств конфигурирования ASP.NET и IIS 8, любые изменения, внесенные непосредственно в файл web.config, немедленно отражаются в консоли управления, и наоборот.

Давайте сначала рассмотрим возможности конфигурирования аутентификации с помощью форм из среды консоли управления IIS 8. Конфигурировать аутентификацию с помощью форм можно с использованием средства настройки аутентификации консоли управления IIS 8, как показано на рисунке ниже:

После разрешения аутентификации с помощью форм подобным образом также понадобится сконфигурировать необходимые правила авторизации. Наиболее важно добавить правило deny для анонимных пользователей с помощью средства конфигурирования авторизации в консоли управления IIS 8:

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

Вы заметите, что аутентификация с помощью форм, сконфигурированная IIS, как и следовало ожидать, находится в разделе . Но по умолчанию (и если вы ранее не добавили этого вручную), никаких правил авторизации там не будет. Как упоминалось ранее, не все опции конфигурации по умолчанию помещаются непосредственно в файл web.config. Авторизация URL — одна из таких опций конфигурации.

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

При запуске IIS 8 в интегрированном режиме (выбираемом по умолчанию) IIS использует канал обработки HTTP для обработки как основанных на ASP.NET HTTP-модулей, так и встроенных HTTP-модулей IIS 8.

Поскольку аутентификация с помощью форм реализована в виде HTTP-модуля ASP.NET, ее можно использовать для любого веб-приложения и виртуального каталога, сконфигурированного в IIS, который функционирует в интегрированном режиме. Это значит, что аутентификацию с помощью форм можно применять вместе с приложениями других типов, такими как статические HTML-сайты, классические приложения ASP или даже приложения PHP. Все, что потребуется сделать — это настроить веб-приложение как виртуальный каталог и затем сконфигурировать аутентификацию с помощью форм через консоль управления IIS 8. Это автоматически добавит к приложению конфигурацию web.config.

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

Теперь просто откройте доступ к папке, где расположен PHP-файл (например, test.php), как к виртуальному каталогу или веб-приложению внутри IIS. После этого можно сконфигурировать аутентификацию с помощью форм и настройки авторизации, как было описано ранее.

Поскольку IIS 8 органично поддерживает аутентификацию с помощью форм, полагаясь на HTTP-модуль аутентификации с помощью форм, поставляемый в ASP.NET, она работает точно также, как работала бы с приложением ASP.NET. Все что нужно — это удостовериться в наличии необходимой страницы входа, которая сама по себе является страницей ASP.NET. Также должны быть доступны части, необходимые для страницы ASP.NET, внутри веб-приложения (или в другом виртуальном каталоге, если применяются cookie-наборы аутентификации между приложениями).

На рисунке ниже показана страница PHP вместе со страницей входа ASP.NET в виртуальном каталоге. Аутентификация с помощью форм просто конфигурируется через управляющую консоль IIS 8, как было описано ранее:

Однако просто поместить содержимое PHP вместе с основанными на ASP.NET страницами входа и сконфигурировать аутентификацию с помощью форм еще недостаточно. Когда вы попытаетесь выполнить переход на страницу PHP, аутентификация с помощью форм пока работать не будет. В зависимости от аутентификации и правил авторизации, вы либо получите ответ «unauthorized» («неавторизовано»), либо сможете переходить к странице PHP без приглашения на вход.

Причина в том, что по умолчанию управляемые HTTP-модули, в том числе и модуль аутентификации с помощью форм, настроены так, что выполняются только по запросу кода, основанного на ASP.NET. Поэтому чтобы заставить работать аутентификацию с помощью форм, потребуется изменить это поведение, вызвав средство конфигурации HTTP Modules в консоли управления IIS 8 когда ваше веб-приложение выбрано. Затем нужно отобразить детальную информацию для модуля FormsAuthentication, сконфигурированного в списке модулей, как показано на рисунке ниже:

Открыв средство конфигурации HTTP Modules, найдите FormsAuthentication и дважды щелкните на нем или выберите ссылку Edit (Правка) в панели задач справа. В открывшемся диалоговом окне снимите отметку с флажка Invoke Only for Requests to ASP.NET Applications or Managed Handlers (Вызывать только для запросов к приложениям ASP.NET или управляемым обработчикам), как показано на рисунке ниже:

После завершения этой настройки при обращении к странице PHP в каталоге веб-приложения запрос будет аутентифицирован посредством аутентификации с помощью форм ASP.NET. Конфигурационный файл web.config для веб-приложения будет выглядеть следующим образом:

Конфигурация FormsAuthenticationModule важна. Флажок в неотмеченном состоянии задает preCondition=»», которое по умолчанию установлено в managedHandler.

Источник