Using Active Directory to authenticate users in a WWW facing website

Question

Hi,

I'm looking at starting a new web app which needs to be secure (if for no other reason than that we'll need PCI (Payment Card Industry) accreditation at some point).

From previous experience working with PCI (on a domain), the preferred method is to use integrated windows authentication which is then passed all the way through the app to the database using kerberos (so the NT user has permissions in the DB). This allows for better auditing as well as object-level permissions (ie an end user can't read the credit card table).

There are advantages in that even if someone compromises the webserver, they won't be able to glean any/much additional information from the database. Also, the webserver isn't storing any database credentials (beyond perhaps a simple anonymous user with very few permissions for simple website config)

So, now I'm looking at the new web app which will be on the public internet. One suggestion is to have a Active Directory server and create windows accounts on the AD for each user of the site. These users will then be placed into the appropriate NT groups to decide which DB permissions they should have (and which pages they can access).

ASP.Net already provides the AD membership provider and role provider so this should be fairly simple to implement.

There are a number of questions around this - Scalability, reliability, etc... and I was wondering if there is anyone out there with experience of this approach or, even better, some good reasons why to do it / not to do it.

Any input appreciated

Regards

Basiclife

Answer 1

couple ideas

Run AD/AM - Active Directory Application Mode.

It scales well. It's the same core code as AD. Similar management capabilities. Solid reliability. Works with the ASPNET AD Membership Provider.

And it's included in Windows.

---

Also consider exploring a federated identity system, via ADFS 2.

unlike AD/AM, this approach is fairly leading-edge. The final version of the ADFS v2 server is not yet available from Microsoft, but it is at "release candidate" stage. If you have the stomach to be an early adopter, ADFS2 holds the possibility to employ a federated identity approach. That means you could accept identity tokens from a variety of existing sources: a google sign-in, a yahoo sign-in, any OpenId source, and use that as the identity on your site. Users would not have to "register" and authenticate to you. Instead, your site would honor the identity and authentication provided by some trusted third party, and perform authorization based on that identity.

Answer 2

Having used ADAM in a project, I found it to be bear. Documentation for developers can be sparse, it has quirks that differentiate it from full AD and, most importantly, I could not get a straight answer from MS as to whether it will be fully supported in the future. The impression I got was that ADAM was the bastard child and that the new Federated services (ADFS) was where they wanted people to go. Just moving the ADAM store from one member server to another was a pain. Now that said, my issues with ADAM had to do with development against and maintenance of the store, It definitely has the ability to scale and it was reliable. That said there are times when you need to delve into 80th level spells of LDAP/Directory magic to figure what it is or is not doing.

For a public facing site, AD/ADAM might be overkill IMO. You could use alternate MembershipProviders like the SqlMembership provider to get the good level of security with respect to credentials. If you wanted to go further, you could use database encryption (SQL Server at least has this ability built-in) to encrypt information that falls into the PII (Personally Identifiable Information) arena and of course encrypt the backups. The advantage that a database backed authentication store has is that you have all the tools that your database product provides to scale out, do backups, control access and so on.

EDIT: Let me add, that with .NET you can setup your site so that it runs under a Windows user and connects to the database using Windows Authentication (assuming the db supports it). Thus, no credentials need to be stored in a config file. However, if you had to store credentials for whatever reason, you can then use DPAPI to encrypt the credentials in the config file.

ADDITION In response the question about securing encryption keys you have a couple of choices. The first is to simply hash the credit card numbers. That greatly simplifies any problems with access to the data however, it means that the customer would have to re-enter their card number for each purchase. If you want to remember the customer's card number, then you move into a new realm of maintenance of the decryption keys. In this scenario, you absolutely should use Windows Authentication to the database and look into SQL Server 2008's Extensible Key Management feature which lets you hook-in a third-party key management program into SQL's encryption functionality. In this way, only the website user would have access to the keys used for decryption. There are other solutions to ensure that the website cannot be compromised. The greater worry is that someone gets a copy of the database undetected. Here's a link on using SQL Server to be PCI compliant:

Deploying SQL Server 2008 Based on Payment Card Industry Data Security Standards (PCI DSS) Version 1.2.

Answer 3

This is not a direct answer but having a AD user account means you need a windows CAL for that user. Another way would be to issue client certificates to user and map client certs to AD users in IIS.

You might also consider AzMan with SQL store available from Windows 2008 onwards or the open source netsqlazman.