Мой супервизор в офисе говорит мне, что он видел демонстрацию с предварительной версией Microsoft "Geneva" (теперь Windows Identity Foundation), где разработчик сделал следующее:
Он настроил своего рода веб-приложение ASP.net, где пользователь мог войти в систему с помощью специализированной системы входа в систему. Негласно, веб-приложение регистрирует пользователя в как пользователь в Active Directory.
Пользователь входит в систему.
После того как пользователь зарегистрирован, выполнения потока веб-приложения ASP.net как зарегистрированный пользователь на время сессии пользователя и может получить доступ к ресурсам в сети (таким как выполнение SQL-запросов на таблицах, доступ которых является управляемым Active Directory),
Шаги 2) и 3) являются точно тем же как использованием установки "Integrated Windows Authentication" на вкладке "Directory Security" настроек веб-сайта в IIS. Шаг 1), отличается, потому что мы используем пользовательскую систему входа в систему в противоположность аутентификации Kerberos.
Мы хотим настроить одно из наших приложений для работы точно, как описано в 1), 2) и 3). Однако вся документация, что я посмотрел Windows Identify Foundation относительно, о безопасности Cardspace и Federated. У нас есть нулевой интерес к использованию любой из этих технологий прямо сейчас.
Мы просто хотим смочь зарегистрировать пользователей в в Учетные записи Active Directory негласно.
Да, мы попробовали ActiveDirectoryMembershipProvider
с Forms Authentication
, но это - полный клудж к на самом деле ресурсам доступа на олицетворении требования сети на каждой странице!
Jan 7 ОБНОВЛЕНИЯ, 2010. Хорошо, я работал в этом некоторое время и всем, что мне удалось подойти, далек от того, чего я хочу достигнуть. Возможно, функциональность, которую я хочу, не находится в версии выпуска WIF.
Вот то, где я в теперь. Я нашел некоторую документацию относительно MSDN, который указывает, что существует три различных идентификационных данных, используемых в ASP.net: идентификационные данные, указанные HttpContext.Current.User
, идентификационные данные, указанные Thread.CurrentPrincipal
, и наконец идентификационные данные, указанные WindowsIdentity.GetCurrent
. ссылка
В одном примере того, где я хочу использовать процесс, который я надеюсь разрабатывать, я хочу выполнить SQL-запрос как зарегистрированный пользователь. В моем отладчике я вижу, что легко установил пользователей HttpContext и Потока на зарегистрированного пользователя. Однако, когда я соединяюсь с SQL-сервером с помощью аутентификации Windows, он всегда всегда всегда соединяется как WindowsIdentity.GetCurrent
пользователь и тот пользователь являются всегда всегда всегда идентификационными данными процесса ASP.net, если я не использую аутентификацию Windows с олицетворением. Я абсолютно не могу использовать аутентификацию Windows со своим приложением, потому что мои пользователи должны войти в систему путем проигрывания волшебной песни флейты, и аутентификация Windows не имеет никакой поддержки входа в систему с волшебными песнями флейты.
Для разъяснения нет никакой проблемы получить a WindowsIdentity
представление зарегистрированного пользователя (кто вошел в систему с волшебной песней флейты). Проблема состоит в том, что я не могу использовать это WindowsIdentity
выполнить SQL-запросы для моего пользователя.