I am searching at beginning a brand new web application which must be secure (if for not one other reason than that we'll need PCI (Payment Card Industry) accreditation sooner or later).

From previous experience dealing with PCI (on the domain), the most well-liked method is by using integrated home windows authentication that is then passed completely with the application towards the database using kerberos (therefore the NT user has permissions within the DB). This enables for better auditing in addition to object-level permissions (ie an consumer can't browse the charge card table).

You will find advantages for the reason that even when someone compromises the webserver, they will not have the ability to glean any/much more information in the database. Also, the webserver is not storing any database qualifications (beyond possibly an easy anonymous user with very couple of permissions for straightforward website config)

So, now I am searching in the new web application which is around the public internet. One suggestion is to possess a Active Directory server and make home windows accounts around the AD for every user from the site. These customers will go in to the appropriate NT groups to determine which DB permissions they ought to have (and which pages they are able to access).

ASP.Internet already offers the AD membership provider and role provider so this ought to be quite simple to implement.

You will find numerous questions for this - Scalability, reliability, etc... and I'm wondering if there's anybody available with connection with this method or, better still, good quality explanations why to get it done / to avoid it.

Any input appreciated



Getting used ADAM inside a project, I found it bear. Documentation for designers could be sparse, it's eccentricities that differentiate it from full AD and, most significantly, I possibly could not obtain a straight answer from MS whether it will likely be fully supported later on. The sense I acquired was that ADAM was the bastard child which the brand new Federated services (ADFS) was where they wanted individuals to go. Just moving the ADAM store in one member server to a different would be a discomfort. Now nevertheless, my difficulties with ADAM had related to development against and upkeep of the shop, It certainly is able to scale also it was reliable. Nevertheless you will find occasions if you want to explore 80th level spells of LDAP/Directory miracle to find what it's or perhaps is not doing.

For any public facing site, AD/ADAM may be overkill IMO. You could utilize alternate MembershipProviders such as the SqlMembership provider to find the good degree of security regarding qualifications. Should you took it further, you could utilize database file encryption (SQL Server a minimum of has this ability built-in) to secure information that grouped into the PII (Your Personal Data) arena not to mention secure the backup copies. The benefit that the database backed authentication store has is you have the various tools that the database product provides to scale out, do backup copies, control access and so forth.

EDIT: Allow me to add, by using .Internet you are able to setup your website to ensure that it runs within Home windows user and connects towards the database using Home windows Authentication (presuming the db supports it). Thus, no qualifications have to be saved inside a config file. However, should you needed to store qualifications for reasons uknown, after that you can use DPAPI to secure the qualifications within the config file.

ADDITION In reaction the question about acquiring file encryption secrets you've got a handful of options. The very first is to merely hash the charge card amounts. That greatly simplifies any issues with use of the information however, this means the customer would need to re-enter their card number for every purchase. If you wish to recall the customer's card number, then you definitely transfer to a brand new arena of upkeep of the decryption secrets. Within this scenario, you will should use Home windows Authentication towards the database and consider SQL Server 2008's Extensible Key Management feature which allows you hook-inside a third-party key management program into SQL's file encryption functionality. In by doing this, just the website user would have the secrets employed for decryption. You will find other solutions to make sure that the web site can't be jeopardized. The higher worry is the fact that someone will get a duplicate from the database undetected. Here is a link on using SQL Server to become PCI compliant:

Implementing SQL Server 2008 According to Payment Card Industry Data Security Standards (PCI DSS) Version 1.2.