У меня есть пользователь в активном каталоге azure, в моей программе я соберу имя пользователя и пароль конечного пользователя и хочу проверить с помощью активного каталога windows azure.Как проверить учетные данные пользователя активного каталога azure?
Возможно ли это? pl дают некоторую ссылку.
я знаю, с помощью командлетов Power-оболочки, мы можем утверждать, что я хочу знать, есть ли другие способы для проверки пользователя crednetial
Ах, я думаю, вы пытаетесь реализовать сценарий SSO. Попробуйте Adding Sign-On to Your Web Application Using Windows Azure AD! И если у вашего клиента нет подписки Azure, этот пример Multi-Tenant Cloud Application for Windows Azure Active Directory описывает данные с использованием библиотеки аутентификации Azure Active Directory. Надеюсь это поможет.
Ваши ссылки полезны.Но с точки зрения разработчика, мне было бы больше интересно найти способ, где у меня уже есть имя пользователя/домен/пароль и т. Д. Со мной. Поэтому я не хочу открывать окно браузера и позволять пользователю делать это (на данный момент это так). Как выполнить аутентификацию WAAD, когда у нас есть все детали с нами? В настоящее время мы используем 'AuthenticationContext.AcquireToken (ресурс, client-id, resource-app-id-uri)', но как использовать 'AuthenticationContext.AcquireToken (resource, ClientCredential)'? – iammilind
Ссылка на ваш [этот] (http://code.msdn.microsoft.com/AAL-Server-to-Server-9aafccc1/sourcecode?fileId=93566&pathId=1250178454) содержит пример кода, но не уверен, что это применимо или нет. Я не уверен, как использовать часть 'clientSecret' для создания' ClientCredential'. – iammilind
Вы говорите, что вы «соберете имя пользователя и пароль конечного пользователя и хотите проверить с помощью активного окна windows azure» - я уверен, что это НЕ возможно, и я точно знаю, что это нецелесообразно. Это противоположность тенденции подходов, таких как OAuth, где пользователи могут входить в систему во многих приложениях с использованием тех же учетных данных (и важная часть - критическая), не раскрывая тем самым «многие приложения» свой пароль.
Это идея федеративной аутентификации и более безопасная модель, чем более старые подходы, позволяющие всем приложениям, с которыми вы входите, иметь прямой доступ к вашему имени пользователя и паролю. Как правило, в таком потоке, предполагая существующую учетную запись Office 365, новое приложение, которое вы создали и настроенное для аутентификации с использованием O365, будет переустанавливать веб-браузер пользователя на O365, где пользователь вводит имя пользователя и пароль O365, а затем соглашается (один раз), что их можно использовать с этим новым приложением, тогда браузер вернет обратно в приложение с маркером безопасности с некоторыми претензиями. Эти претензии будут включать имя, адрес электронной почты и другие сведения о зарегистрированном пользователе и должны быть достаточными для идентификации пользователя в вашем приложении.
То же самое касается аутентификации, скажем, Facebook или Google - ваше приложение никогда не увидит пароль пользователя напрямую. Это применимо даже для входа в StackOverflow, поэтому вы видели рабочий процесс.
Надеюсь, этот вариант ADAL также может помочь.
ClientCredential encryptedCredentials = Convert.ToBase64String(System.Text.ASCIIEncoding.ASCII.GetBytes(string.Format("{0}:{1}", "[email protected]", "PasswordX")));
httpClient.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue("Basic", encryptedCredentials);
В случае, если кто-то все еще ищет ответ. Поддержка аутентификации пользователя без открытия нового окна для пользователя cred была добавлена в версии ADAL 2.7.10707.1513-rc путем предоставления объекта класса UserCredential перегруженной функции AcquireToken.
public AuthenticationResult AcquireToken(string resource, string clientId, UserCredential userCredential);
Вот пример кода для powershell. $UserCred = new-object Microsoft.IdentityModel.Clients.ActiveDirectory.UserCredential("****@*****", "*****") $result = $AuthContext.AcquireToken($resource,$clientID,$UserCred)
Это доступно только для собственных клиентов, а не для веб-приложений. – BenV
Что вы пытаетесь достичь? Можете ли вы описать схему более высокого уровня вашей схемы аутентификации и авторизации. Основываясь на вашем описании, это звучит так, будто вы пытаетесь что-то довольно небезопасное и «озорное». Есть ли причина, по которой вы не используете аутентификацию на основе утверждений в своем полагающемся стороннем приложении и не разрешаете аутентификации Windows azure active directory (WAAD)? – Nathan
В большинстве приложений, которые я развернул для очень крупных компаний, мы включили AD в источник аутентификации, и я с нетерпением жду того, как Azure AD может заменить это в моих облачных приложениях. Я бы предпочел не писать код аутентификации, если мне это не нужно, и пусть WAAD позаботится обо всем этом для меня, когда я сосредоточусь на том, как авторизация применяется к моей логике приложения. – Graham
Вы когда-нибудь находили решение для этого. Я пытаюсь сделать то же самое? – Gotts