How should one manage authentication on custom line of business software

Question

I am writing line of business software for a company, and we want to authenticate users, so we can manage workflow and do some auditing. Basically my employers don't want me to piggyback off of windows authentication because of certain network restrictions (I really don't want to get into it but its a mixture of poor network setup and bosses wanting to know if there is another way to do it)

I am using c#, wpf, MVVM, PRISM

I've read a bit about hashing passwords, salting, etc and the more I read the more I realise that I really should not be writing the security section of this program, as I am basically faaaaaaar from qualified.

Eric Lippert has a very good basic intro into security, in which he warns the reader at the beginning that you should not be designing your own security system as you do not know enough.

I want to know, what are the alternatives?

• Seeing as I'm not supposed to write it myself, I would like to know where should I get it from?

• Do I hire security experts to write it with?

• Is there a third party security program I should interface with?

• Do I outsource the design but implement it myself?

• Who is the big player in this industry that I should look at?

---

EDIT

In answer to questions raised by Steve:

Where is the data?

• Well this hasn't been decided yet. I thought there might be some system which can house the authorisation data (and calls to and from it) in a secure way and was wondering what that system might be. However we have a SQL server which I imagine will probably be where the data would be kept. So the data is stored on a Microsoft SQL server and would be accessed somehow by clients on the network (in order for the clients to authenticate). It is conceivable that I write an authentication service that runs on this server and accesses the data directly through SQL (so its not over the network). The clients would then interface with this service.

How are you accessing the data?

• Well as I said its a SQL server. The system is purely internal (we will design a web interface for clients at a later stage but that will probably use some other web-based authentication which as far as I know will be a lot easier because these things are built into most web development technologies). There is a diginet line that has a VPN to a second office which will probably want access as well.

Where do I want to store users?

• We are pretty much ok with anywhere, with 3 restrictions

  • Can't cost too much, so we should probably use technologies we already have (one of our servers, SQL or something like it)

  • Management wants security. As much as is possible on our small budget.

  • Management is a bit touchy about hosting such sensitive data externally, so we pretty much have to own and control where ever it's stored.

How do you want to manage users?

• To be honest I'm not sure what this question is really asking. However I feel like it is important for me to mention here that we are writing a custom app for the business. This app needs to be able to interface seemingly seamlessly with this solution, so the user logs in through our system (which probably uses an API offered by this solution to make calls directly to the system), and this system's authentication controls what access the user has to our custom app.

The more I talk about it the more I think it is a tall order to get some prepackaged solution here, but I keep coming back to what Eric Lippert said:

"Let me give you all my standard caution about rolling your own cryptographic algorithms and security systems: don't."

I'm not qualified to write this properly. It will not be secure. So what is it that people actually do when developing their own software?

Answer 1

As Graham had said it really depends on what you are wanting to protect against. But given the technology you listed, the big (marketing) push from Microsoft is to use Claims Based Authentication/Authorization through Federation: http://msdn.microsoft.com/en-us/magazine/ee335707.aspx.

However, since that alone probably doesn't help you at all, some more questions might need to be asked:

• Where's the data?
• How are you accessing the data? (E.g. directly through SQL connections/ORM, or through a web service)
• Where do you want to store users?
• How do you want to manage users?

From a technology perspective there are lots of options that don't involve writing things from scratch, including 3rd party products to integrate with. However, the 3rd party products usually exist for very specific feature sets, e.g. multifactor authentication.

EDIT:

So what is it that people actually do when developing their own software?

They continue to write their own security code even though its insecure.

Thinking longer term, you are probably best off creating a WCF service protected by WIF and storing the credentials in the database using ASP.NET Membership providers. There's an open source project that would get you what you need: http://identityserver.codeplex.com/

All calls to the WCF service will require authentication, so the service would be the common interface for various types of applications accessing the data. It does require a little more work, but it will save you in the long run.

Answer 2

Since you're a Microsoft shop, and since it sounds like you'd be comfortable with implementing this if you could piggy-back off the existing domain, have you considered bringing up your own separate AD domain? You presumably already have windows admins around who could look after it.

Other solutions might be a better fit, of course, but this has a certain quick and dirty attraction.

Answer 3

There will be other, more technically useful answers to come, so save your upvotes for them, but if you'll induldge me:

What are your actual security requirements? What is the threat? How strongly do you need to authenticate? Do you even need to authenticate at all?

For example, I genuinely have a business app deployed where the users need to be identified, but not authenticated. i.e. when Bob uses this app, the app needs him to identify himself as Bob, so it can show Bob's data, and so we have an audit trail of what Bob did, but it doesn't need him to prove he is Bob.

Sure, Eve could come along and tell the app she was Bob, but she would gain nothing. I suppose Eve could vandalise the data out of spite, but the app is only accessible from inside the network, and it's very dull, and we have backups, and for that matter we could manually recreate a days data without much trouble.

Answer 4

Given the details in the edit part of the question, I would propose the ASP Membership model. It's dated, but still valid, and seems to fulfill your bulletpoints:

• It's tried an tested (Official and 3rd party documentation available)
• Available for free
• Works with an SQL Database, that you already have
• Has a C#/.NET codebase
• Is intended to be used with a website, via IIS, that you might use anyway
• Will be usable from a desktop client, for example via an API on the above web site.
• Has prebuilt management components