views:

99

answers:

3

I hate to re-invent the wheel so I'm looking for an existing solution to create a simple authentication system for my application. I've experimented for a while with using CardSpace or OpenID inside the application but I can't convince management that these would be working solutions. Of course, I could just build a simple login dialog where username, domain and (hashed) password is stored inside a database table and I've done such a thing many times already. I hate this solution since I feel it's just a weak option. And I don't want to spend too much time trying to make the whole logon system as secure as possible, especially since I suspect that there should be existing solutions for this.

So, next to OpenID/OpenAuth and CardSpace, are there any other Authentication solutions that can be used from a Delphi/WIN32 application?


Right now, the application will be used by many customers. Most are single-user environments, although it's likely that some of those will start to have two to 5 users once this authentication system is added. But we want to support a customer who needs to allow about 500 different users on the same application. These are spread over about 100 offices but they all connect to the same SQL Server database. (MS Access right now, but we're making it possible for this user to use SQL Server instead.) To make matters even more interesting, the customer uses Citrix to centralize the user systems and the application has straight access to the SQL Server database. It's not an ideal setup but then again, the customer isn't really paying for this. We're just setting up a test environment. A proof-of-concept which the customer will test for us. Flaws will be solved later on. But right now I need quick solutions and one of them is a practical authentication system where I don't have to write a lot of code.

+1  A: 

I would suggest then

  1. Delphi - since you are using Delphi :)
  2. Open source - since you need to be able to figure out what is wrong if there is a problem, you probably want it cheap.

So, here are some solutions:

http://www.torry.net/pages.php?id=313

 CoWindowsAccount v.1.0
 SSecurity v.1.2.1.3

http://free-password-manager-plus.software.informer.com/1.6/

Larry Watanabe
It doesn't have to be cheap, as long as it can be used to create a demo. But SSecurity looks the most promising.
Workshop Alex
+1 thanks for the feedback Alex
Larry Watanabe
Based on this question, I've tried SSecurity. No documentation and it seems the author is not actively developing it anymore, but the source is there and it seems nice.
Leonardo Herrera
+1  A: 

It might work for your purposes, but why not ask Windows for the current domain and user name, and use them as unique IDs. Windows has already done the authentication, and it saves the users making up new passwords or anything. I've used this to good effect. I also made it optional to include the machine name in the ID, so that the same user on different computers would also be unique.

mj2008
Not all users have an unique Windows authentication token. About 10% of all users share the same Windows account in some way. These use a kind of remote desktop application which they can use from any web browser. But the serverside software uses only a single Windows account, not one account per user.
Workshop Alex
+1  A: 

Have you considered using SQL Server authentication and not allowing authentication for those using an Access Database?

If you use the new SQL Server Native Client and SQL Server 2005 you can have passwords expire and change them from your client application. All of the tools to create and manage user accounts are built into SQL Server Management Studio. And if you decide later to support Windows Authentication you just need to modify your connection string.

We have a system where users on the network use Windows Authentication so they don't need to worry about another user name and password. For users that access the system via a VPN and non-domain joined machines they use SQL Authentication.

Here is the MSDN Page that talks about dealing with passwords programmatically in SQL Server 2005

You do need to make sure that SQL Server Native Client is installed, but that is simple compared to the rest of ADO.

Mark Elder