У меня есть корпоративное веб-приложение, которое будет интегрировано со службой единого входа (SSO) через Встроенная проверка подлинности Windows (IWA). Служба SSO обеспечивает только аутентификацию (не авторизацию). Это веб-приложение будет обрабатывать авторизацию через специальный модуль авторизации. Мы запускаем IIS 6 в Windows 2003.
Как только пользователь проходит аутентификацию через IWA, IIS по умолчанию выполняет веб-страницу в контексте пользователя, вошедшего в систему. Обычно у нас есть объект группы безопасности Active Directory, которому мы назначаем разрешения на чтение / выполнение в каталоге веб-сайта - любой объект пользователя, который член этой назначенной группы безопасности может видеть / запускать веб-страницу. Любой пользователь AD, который успешно проходит аутентификацию в AD, но не принадлежит к этой группе безопасности, получает HTTP 401 (доступ запрещен).
Однако в этом проекте мы не хотим поддерживать добавление / удаление пользовательских объектов AD для указанной группы безопасности. Вместо этого мы решили назначить группе Authenticated_Users права на чтение / выполнение файлов каталога веб-сайта. Таким образом, если вы можете аутентифицироваться, вы по умолчанию сможете увидеть / выполнить запрос страницы.
Это безопасно? С точки зрения моей команды, это безопасно, если модуль авторизации в этом веб-приложении выполняет свою работу.
Кто-нибудь еще делает это или у вас есть другой подход к управлению авторизацией при использовании встроенной проверки подлинности Windows в IIS?
Пока ваш модуль авторизации работает так, как заявлено, у вас не должно возникнуть никаких проблем. Это разделение (аутентификация и авторизация), о котором часто забывают. Вы просто берете на себя ответственность за авторизацию (в приложении), но, очевидно, именно этого вы и хотите! Как вы сказали, все, что будет делать группа безопасности Windows, - это предоставлять механизм аутентификации, который не имеет ничего общего с фактическими разрешениями в вашем приложении.