tags:

views:

32

answers:

1

Hi all,

I'm wanting to secure ELMAH in an internet facing application. The system uses Forms Authentication, but doesn't currently have any non-user accounts (e.g. Admins). The user accounts are set up in an automated fashion.

I don't really want to shoehorn any admin accounts into the system (the current DB schema for the users would be quite inappropriate for storing an admin user in), so I was thinking of corrupting the Forms authentication by checking for an SSL client certificate. If I pick all the right options in IIS, I believe I can ensure that only certificates issued by our internal CA (currently used for non-production sites needing SSL certs) will get passed through to ASP.Net.

I can then use the presence of a Valid ClientCertificate (checking IsPresent and IsValid properties of Request.ClientCertificate) to know that this is a connection from an internal user, and set the Forms Authentication cookie as "Diagnostic" or "Admin" (Or any other special username), and then secure elmah.axd using any of the usual methods suggested for doing it via Forms Authentication.

So my question is - am I overcomplicating things, missing something obvious, opening a massive security hole, etc?

A: 

Why don't you just store an admin user account credentials within Web.Config and lock down the URL using Forms Authentication anyway?

Edit

Ok, if the application is entirely internal anyway, why not secure a subdirectory of your site (e.g. myapplication.domain.com/exceptions/elmah.axd or even just myapplication.domain.com/elmah.axd) using Active Directory and set authorisation through IIS?

Phil.Wheeler
Ah, I forgot to mention that there will be multiple people who may genuinely need to access the diagnostics. I generally don't like multiple people sharing a single set of credentials (although in this case it may be okay)
Damien_The_Unbeliever