How to validate user name password with azure active directory

[manjunathreddy1]

Hi All,

Can anyone tell me how to validate user name and password with azure active directory from power apps 

[cchannon]

From within a canvas app, a logged in user is already validated with Active Directory, by definition. The User functions in PowerApps will give you access to that user's name, email, and image if you like.

From within a model-driven app, the current user is again validated with AD, by definition. Here you can use Xrm.Utility.getGlobalContext().userSettings to get access to the user's ID, name, and other personal settings.

From within a PCF, you are deprived of these things (although again, in order to be running the app they must have authenticated). So if you need to validate the user for some reason, you are left with pretty much no options other than including adal and using it to check the current user's token.

[cchannon]

Really, the short answer is, that a powerapp has no business ever holding a user's password under any circumstances, so you should always just trust in what AD has already done, or if you need to do more (to authenticate with a downstream system, maybe?) then you can retrieve tokens AD has already provided.

[manjunathreddy1]

Actually we have a requirement to implement E signature, when sign button is clicked we need to show popup for users to enter username and password after that it needs to be validated and details such as user name, job title, signed datetime needs to be shown on form 

[ben-thompson]

Why?

The user is already in the system and has authenticated themselves via whatever levels of security have been set up (be it integrated SSO, username password or 2FA). So assuming care at all about security it's not going to be an issue.

Today I digitally signed a $15,000 credit agreement by just checking a checkbox. You really, really don't need anything more than that - I guess you could ask for job title if you haven't got it but you can pull all the information you need as the checkbox or sign button is checked and the form is saved..

[cchannon]

I agree. Your app should never, ever be asking a user for their password. There is no good reason to do it; they have already signed in. Popping an authentication prompt adds no security whatsoever, and worse - if you are collecting this data yourself you open up new (and serious) security vulnerabilities you do not want to contend with. Check with your customer; maybe they'd be ok with just capturing a signature in a draw box along with the username and timestamp.

---

Now, for the sake of argument let's say that your customer doesn't want to listen to that argument and 100% insists that you MUST prompt for username and pass (again, I strongly discourage this, just offering a theoretical solution). In that case, you still do not want to handle the password yourself because it would actually be much LESS secure than never prompting at all. So here the only reasonable solution is to use a PCF and include the Active Directory Authentication Library (adal) to request a token from Active Directory. I have never had the need to request a token for a user that already has one, so this might require some weird workarounds (and I don't know what they'd be), but if you fuss with it enough you can probably figure out how to get AD to prompt the user for a name and pass even though they are already logged in, then return you a new validated token or failure. But here's the thing: you're taking on a big dev effort, using an authentication protocol in a way it wasn't designed to be used (therefore risking downstream complications), and at the end of all this your result is exactly the same: you're only going to capture a username and timestamp to prove the "signature" so why do it at all? It just makes no sense.

[cchannon]

Oh, another option you might want to consider: DocuSign has a SharePoint integration that lets you push a document up to DS for digital signature and forces the user to sign in with DocuSign to do it. The licensing is EXPENSIVE but if youre customer really wants legit e-signatures, this might be an avenue to explore.

[csandiford]

Hi. I had a scenario where I wanted to confirm that the authorized user was still in control of their machine.

I don't want to store the password. If the authorized user is logged in, had to step away for 5 minutes planned or unplanned, I did not want an unauthorized user with physical access to the machine to be able to execute a function under the authorized user's ID.

But I understand the reservation, if a custom app accepts the password but doesn't properly encrypt/sign/hash, or whatever MS does to protect their passwords, it negates MS' security.

I settled for a custom user/password specific to the app. I did not like the additional layer of administration but I thought it was better than forgoing the additional check.