Здравствуйте Alex Ostapenko, вы писали:

AO>Сходу видятся 2 варианта:
AO>1) конфигурационный файл;
AO>2) ключи в реестре.
AO>В обеих случаях привязка настройки идет по url сайта.

Сейчас я пишу подобный фильтр. Собственно он уже написан, но тоже возникла необходимость конфигурирования.
В связи с этим возникла идея внести изменения в архитектуру фильтра: создать COM-объект, который будет реализовывать всю функциональность (сличать логин/пароль с данными из БД, возвращать имя NT-го аккаунта для соответствующей роли пользователя, кэшировать данные и т.п.), а сам фильтр будет только обращаться к запущенному экземпляру объекта (или создавать новый, если нету запущенного) и использовать эту функциональность. Понятно, что можно и другим приложениям предоставить возможность управления этим объектом — например можно чистить кэш или менять какие-то настройки налету. Тогда можно и настройки не читать каждый раз из реестра или конфигурационного файла, а сделать это только один раз, а потом держать в памяти. При изменении же каких-то настроек можно эти изменения передавать объекту,как я уже говорил, налету.
Как вам такая схема?
С уважением, Виталий.