Мой руководитель в офисе говорит мне, что он видел демонстрацию с предварительно выпущенной версией Microsoft «Женева» (теперь это Windows Identity Foundation), где разработчик следующее:Использование Windows Identity Foundation для входа в приложение ASP.net
Он создал своеобразное веб-приложение ASP.net, где пользователь мог войти в систему, используя индивидуальную систему входа в систему. За кулисами веб-приложение регистрирует пользователя в качестве пользователя в Active Directory.
Пользователь регистрируется в.
После того, как пользователь вошел в систему, поток веб-приложение ASP.net работает как зарегистрированный пользователь на время сеанса пользователя и может получить доступ к ресурсам сети (например, выполнение запросов SQL таблиц доступа которых контролируется Active Directory)
шаги 2) и 3) точно так же, как и с помощью «встроенной проверки подлинности Windows» настройки на вкладке «Безопасность каталога» из настройки веб-сайта в IIS. Шаг 1) отличается тем, что мы используем настраиваемую систему входа в систему, а не проверку подлинности Kerberos.
Мы хотим настроить одно из наших приложений так, как описано в пунктах 1), 2) и 3). Тем не менее, вся документация, которую я видел в отношении Windows Identify Foundation, относится к Cardpace и Federated Security. Мы сейчас заинтересованы в использовании любой из этих технологий.
Мы просто хотим иметь возможность регистрировать пользователей в учетных записях Active Directory за кулисами.
Да, мы пробовали ActiveDirectoryMembershipProvider с Forms Authentication, но это полный клочок для фактического доступа к ресурсам в сети, требующим олицетворения на каждой странице!
ОБНОВЛЕНИЕ 7 января 2010. Хорошо, я работал над этим некоторое время, и все, что мне удалось найти, отстает от того, чего я хочу достичь. Возможно, функциональность, которую я хочу, не входит в версию WIF версии.
Вот где я сейчас. Я нашел документацию по MSDN, которая указывает, что в ASP.net есть три разных идентификатора: идентификатор, указанный HttpContext.Current.User, идентификатор, указанный Thread.CurrentPrincipal, и, наконец, идентификатор, указанный WindowsIdentity.GetCurrent. link
В одном примере, где я хочу использовать процесс, который я ищу для разработки, я хочу выполнить SQL-запрос как зарегистрированный пользователь. В моем отладчике я вижу, что я легко устанавливаю пользователей HttpContext и Thread для зарегистрированного пользователя. Тем не менее, когда я подключаюсь к серверу SQL с использованием проверки подлинности Windows, он всегда всегда подключается как пользователь WindowsIdentity.GetCurrent, и этот пользователь всегда всегда является идентификатором процесса ASP.net, если я не использую проверку подлинности Windows с олицетворением. Я абсолютно не могу использовать Windows Authentication с моим приложением, потому что мои пользователи должны войти в систему, сыграв песню с волшебной флейтой, и Windows Authentication не поддерживает вход в систему с волшебными песнями флейты.
Чтобы уточнить, нет никаких проблем с получением WindowsIdentity, представляющим зарегистрированного пользователя (который вошел в систему с помощью песни с волшебной флейтой). Проблема в том, что я не могу использовать этот WindowsIdentity для выполнения SQL-запросов для моего пользователя.
Мой руководитель очень специфичен, что он не хочет использовать олицетворение. Кроме того, конечный пользователь будет регистрироваться, играя песню на волшебной флейте. Если песня правильная, пользователь автоматически регистрируется с использованием учетной записи AD. У меня нет абсолютно никакого отношения к тому, что пользователь входит в систему, играя песню на волшебной флейте. Что мне нужно - это способ заставить программу вести себя так, как если бы они вошли в систему с аутентификацией Windows, как только они правильно сыграли волшебную флейту. –
Нет, ты просишь невозможного. Аутентификация Windows использует олицетворение, если ваш супервизор говорит, что вы не можете его использовать, тогда вы не можете имитировать проверку подлинности Windows. – blowdart
Спасибо, blowdart. Я должен исправить себя. Я имел в виду, что при использовании Windows Authentication с IIS веб-сервер прозрачно олицетворяет зарегистрированного пользователя. При проверке подлинности форм я должен делать олицетворение программно, чего мы хотим избежать; Кажется, что AdMembershipProvider не помогает мне в этом. Я не могу выдавать себя за файл cookie с проверкой подлинности. My sup. говорит, что он видел демоверсию, где Женева каким-то образом использовалась, чтобы сделать ее так, чтобы пользователь вошел в систему с учетной записью AD автоматически, даже если пользователь входит в систему со своей магической флейтой. –