How to implement security component in Windows Forms?

江枫思渺然 提交于 2019-11-29 10:20:49

Most times a Windows Forms application is used in an internal network with Windows Domain accounts.
In this case you should use "Integrated security" to connect to the database and test if user is authenticated with

 WindowsIdentity winIdentCurrent = WindowsIdentity.GetCurrent();
 if (winIdentCurrent != null)
 {
      Console.Write("WindowsIdentity.GetCurrent(): ");
      Console.WriteLine(winIdentCurrent.Name);
      Console.Write("WindowsIdentity.GetCurrent() IsAuthenticated: ");
      Console.WriteLine(winIdentCurrent.IsAuthenticated);
      // Everything is fine, trust Windows API :-)
 }

otherwise
authenticate the user/pass via your own method (db call)

  1. use a generic connection string
    (not recommended)
  2. set the user/pass of the connection string to your authenticated user/pass

AND set the Thread.CurrentPrincipal to your own Principal object

Since you don't have an accepted answer and since I stumbled on this question researching another, I will endeavor to give you some pointers.

As has been pointed out, user management and role-based security in a win forms app is not something that will actually work client-side. In a web analogy, imagine trying to implement all of your security using only javascript and cookies, keeping no information on the server-side. It's insecure by default.

As has also been suggested, you can implement security on your database and have your users connect directly to the database from your win form. I would highly recommend that you do NOT pursue such a course. User management will become a nightmare. You need a middle tier.

What you should do is build a web service that implements role-based security (since you're familiar with it -- there are better authorization options out there) and has a custom authentication store. If you use WCF to build the web service, you can use the same RoleProvider and MembershipProvider classes that you're used to in ASP.NET.

That web service handles all of the business logic of your system and is responsible for connecting to the database. It provides a secure layer of abstraction and reduces the amount of database administration you need to do in order to manage your users. Your win forms app becomes a UI shell, responsible only for handling user interactions and up-front data validation (you should also validate at the middle tier) and nothing else.

Microsoft released Client Application Services to do exactly what I think you are looking for...

http://msdn.microsoft.com/en-us/library/bb384297.aspx is the official doc http://aspalliance.com/1595_Client_Application_Services__Part_1 is a nice tutorial (with screenshots etc)

I was looking for the same and couldn't find anything until now. Check this out:

Not much here: NET Providers in WinForms http://windark.net/blog/PermaLink,guid,5341a7d0-4eab-473d-9143-a3fa6c41db90.aspx

The solution is here. A good sample (in VB): Using the ASP.NET membership provider in a Windows forms application http://www.theproblemsolver.nl/usingthemembershipproviderinwinforms.htm

But then I thought, is there someone that also wrote the aspnet controls equivalent for Winforms ? The start is here in that MSDN Mag article: Unify Windows Forms and ASP.NET Providers for Credentials Management http://msdn.microsoft.com/en-us/magazine/cc163807.aspx

I hope this answers your question ;)

For a login form, I use my own component that is a wrapper around a p/invoke call to CredentialsUIPromptForCredentials (credui.dll), see this MSDN article for more info. It provides features such as the ability to securely remember users' passwords.

It's kind of surprising that this isn't available in the Framework. Possibly because credui.dll is only available on XP and later, in which case we may see it in a future version of the framework.

As for role-based security, it's inherently insecure in a client app, since a smart user has access to your source code with a disassembler.

So while you can use the ASP.NET RoleManager in a WinForms app, it's not actively encouraged. With RoleManager the user would simply need to replace your RoleManager with his own more liberal implementation in the configuration file to bypass your carefully crafted authorization rules.

The secure way to go is to prompt for credentials (or use windows credentials), and pass these to a service tier (either the database directly, or e.g. a web service) for authentication.

If you are connecting directly to the database (no middle tier), you need to apply your security at the database level.

If you have any more information about whether you are planning on connecting directly to the database from the client machine or via a web service etc I can update my answer to reflect that.

When connecting directly to the database you need to ensure that the database is secure from not just your application but anybody that can connect to SQL Server. You could use windows authentication to connect to SQL Server and set up the roles based on that.

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!