How to validate azure active directory user creden

Question

I have a set of users in azure active directory; in my program I will collect the user name and password of an end user, and want to check against windows azure active directory.

Is it possible? Please provide some reference.

I know we can validate using Power-shell cmdlets; I want to know if there is any other way to validate user credentials.

Answer 1

Hope this ADAL option might also helps.

ClientCredential encryptedCredentials = Convert.ToBase64String(System.Text.ASCIIEncoding.ASCII.GetBytes(string.Format("{0}:{1}", "[e-mail]", "PasswordX")));
httpClient.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue("Basic", encryptedCredentials);

Answer 2

Ah, I think, you're trying to implement a SSO scenario. Try Adding Sign-On to Your Web Application Using Windows Azure AD! And if your customer does not have an Azure subscription, this Multi-Tenant Cloud Application for Windows Azure Active Directory sample describes the details with using Azure Active Directory Authentication Library. Hope this helps.

Answer 3

In case someone is still looking for an answer. Support for authenticating user without opening a new window for user cred was added in ADAL version 2.7.10707.1513-rc through providing an object of class UserCredential to an overloaded function of AcquireToken.

public AuthenticationResult AcquireToken(string resource, string clientId, UserCredential userCredential);

Here is a sample code for powershell. $UserCred = new-object Microsoft.IdentityModel.Clients.ActiveDirectory.UserCredential("****@*****", "*****") $result = $AuthContext.AcquireToken($resource,$clientID,$UserCred)

Answer 4

You say that you "will collect user name and password of an end user and want to check against with windows azure active directory" - I am pretty sure this is NOT possible, and I know for sure it is not advisable. This is the opposite of the trend of approaches like OAuth where users can login on many applications using the same credentials (and the part coming up is critical) without ever revealing to those "many applications" their password.

This is the idea of Federated Authentication and is a more secure model than the older approaches of allowing all apps that you log in with to have direct access to your username and password. Typically in such a flow, assuming an existing Office 365 account, the new app you've created and configured to authenticate using O365 will REDIRECT the web browser of the user to O365 where the user types their O365 username and password in, and then agrees (one time) that it is okay for them to be used with this new app, then the browser will REDIRECT back to the app, with a security token with some claims in it. These claims will include the name, email address, and other things about the logged in user and are intended to be sufficient to identify the user in your app.

Same would go for authenticating with, say, Facebook or Google - your app will never directly see the user's password. It would even apply to logging into StackOverflow itself, so you've seen the workflow.