Windows – Authenticate user in WinForms (Nothing to do with ASP.Net)

windowswindows 7windows-authentication

Originally-posted on StackOverflow, cross-posted here as suggested in SO comments.

Intro

I need to password protect some actions in my application, such as loading/saving files, clicking check-boxes, etc. This is a standard C# .Net 4.0, WinForms application which will run on Windows 7 in a corporate network.

I was about to roll my own very basic system (read obfuscation with wide open backdoors) with a text file of users/passwords/permissions (hashed and salted) until after some searching I found what looks like a
tantalizingly simple approach , but I'm having trouble finding a good tutorial on Roles that isn't about ASP.NET.

Question

So does anyone know of one or more tutorials that show me how to:

  1. Create a Windows User/Group and give that User/Group a Role or Permission.
    • Note that I'm testing this from my company's networked laptop, but will deploy it on the customer's corporate network (Not sure if this is an issue, or how tricky this will get).
  2. Create winforms/console app sample with even just a single method that prints "Hello World" if I'm authenticated or throws an exception if I'm not?
  3. I've never done Network Admin or anything related and I keep reading about Active Directory and Local Users Vs Networked Users… I was hoping for an approach where I could build to an Interface and just ask Windows if the current user has permission ABC and not care too much about how Windows figured that out. Then I can make a concrete implementation for each Local/Network/ActiveDirectory/etc. use case as required (or if required… as I don't even know that right now).

Background

- read if interested, but not required to answer question

Just to make sure I'm going in the right direction here, basically I need/want to test this on my development PC to make sure it's going to have a good end-user experience for my customer. The problem is that currently they run an Auto-login script for each computer that runs my application and there are several different operators that use my application throughout the day. The customer wants password protection on certain features of my app and only provide that to certain operators. I have no problem fitting this in, as I've expected the request for a while, I just haven't ever programmed authentication before.

I think it's worthwhile to convince my customer to give each operator their own network account and assign whatever permissions they want to that operator or group, in case they need to fire somebody, change permissions, etc. It also means I just open several options for them and they can group those permissions however they see fit based on internal corporate policies, which I really shouldn't have to be worried about (but will be if I have to roll my own, as they're IT department knows almost nothing of my application).

From what I can tell it also makes my life a lot easier by not having to deal with hashing passwords and encryption, etc. and just handle which Role is required to click this or that button.

Best Answer

I don't know what the current "best practice" method of doing authorization in a .NET-based application is. Here's something I did many years ago in a web-based application I wrote to offload all of the authorization functionality to the operating system itself. (This will probably come off as a dodgy hack written by someone who is a sysadmin first and a developer second.)

  • I enumerated all the permissions in the application and created files in a directory hierarchy to be made selectively available to users assigned to the appropriate role(s). (The files didn't contain anything-- as you'll see below, I just checked to see that the user could read the file.)

  • Created Active Directory groups that identified application user roles.

  • Assigned permission to read the files I created in the earlier step to the Active Directory groups.

When the user authenticated to the application (web-based) an attempt was made to access each of the "permission" files. Based on which succeeded/failed the application could ascertain the user's assigned "role".

For the Customer's IT department altering permission to the application was a matter of changing the ACLs on the "permission" files (if they needed to make radical changes), or more often, just changing user group memberships.

I liked this method because it handles all the "edge-cases" very well-- nested group memberships, security principals from foreign forests, etc. It's also nice because, if those permission files were relocated to a Windows Server 2012 machine, my application suddenly gains the new Dynamic Access Control functionality "for free".

Related Topic