Fog Creek Software
Discussion Board

Welcome! and rules

Joel on Software

ASP.Net impersonation

I'm looking into ASP.Net impersonation for an app I'm writing, and I'm wondering:  how secure is it to put the username/password of your application user in your web.config file? 

Even after setting proper NTFS permissions on the containing folder, I'd still be a bit reluctant to put the password out like that.  Do most people use this technique, or do they perform the login in the code?

Saturday, March 29, 2003

After much deliberation we still feel that still using SQL authentication (rather than Integrated/Windows auth) is the best way -- ie, storing SQL Login + pwd with connection string in a config file. Saying that - yes we have some customers who are uneasy about having that sitting in a plain text config file - so in that case you can simply convert the connection string to a byte array (System.Encoding) and encrypt the byte array using the DPAPI (data protection API - basically encyption where the Windows worries about the key management) and then store the Base64-encoded (System.Convert.ToBase64String) encrypted data in the config file instead.

To use DPAPI in .NET see:

Duncan Smart
Sunday, March 30, 2003

We do this, and it's a great solution.

Brad (
Sunday, March 30, 2003

Why not use "Integrated Security=true" in SQL server connection string?

Term "impersonation" is used in ASP.NET in a specific way. It relates to a Windows authentication mode.
Including line [<identity impersonate="true" />] into <system.web> section of Web.config defines that code executed inside the request executes as a current user identity, not as ASPNET.

Speaking about your question - IMHO, saving user name and password in any place where it available to someone other than the user himself  _IS A BAD IDEA_.
ASP.NET has a nice authentication mechanism - Forms authentication. In the login form you can do any authentication process an then call FormsAuthentication.RedirectFromLoginPage method to create a user authentication ticket.
If you secure your login page with SSL, nobody but the user himself will know his name and password.

If anyway you're going to put the username/password into Web.config, read about the passwordFormat attribute.

8-))) I know, my English is not excellent.

Mikhail Andronov
Monday, March 31, 2003

You can start here:

Mikhail Andronov
Monday, March 31, 2003

Thanks for the helpful replies, but maybe I'm not explaining my question clearly enough?

I have an application set up with Windows Authentication (I'm in one of those rare situations where all the clients are IE 6 on the local intranet).  However, I don't have Impersonation set up. 

When I look at which user is accessing the Access DB, it's the ASPNET user.  From what I've seen, I can either add impersonation and provide a user/pass in the web.config, or perform a login inside the code and create a WindowsImpersonationContext to execute the required code.

I would rather have a unique username for my application.  Is this a good idea, or should I just turn on impersonation and impersonate each individual user?  I suppose with Windows Authentication, I already have to manage the NTFS permissions anyway...

Monday, March 31, 2003

Given that .config files are explicitly blocked from being delivered by IIS, I wouldn't worry too much about storing the impersonation password in a config file. If your server gets hacked far enough that someone can get that file, you have serious problems already.

But note that Access itself doesn't do integrated security - that is, you'll get the impersonated user trying to open the Access database, but they won't log into Access' own security system if you're using that.

Mike Gunderloy
Monday, March 31, 2003


What users need access to the .Config files then (as far as NTFS permissions)?  Administrators and the ASPNET user?

As for Access, I realize that.  Hopefully I can use that as justification to move the app to SQL Server...

Tuesday, April 1, 2003

>"perform a login inside the code and create a WindowsImpersonationContext"

Well. if you do this then you are burdened with the responsibilty of storing and managing a full Windows userid & password. We considered this and came to the conclusion that we'd rather just manage a SQL Login username/password because, er, it ISN'T a windows username/password - ie, you can't use a SQL Login to log actually into a machine.

SQL Logins are still useful after all these years because you can use them basically as roles your application can use (yes I know about SQL's application roles too). Create SQL Logins called things like WebReadOnlyUser, WebReadWriteUser etc. and them as part of the connection string ("UID=...;PWD=...") in web.config encrypted or plain text, whatever keeps the customer happy. The only Windows a/c's that need access would be Administrators (full control) and ASP.NET (read only).

>"I would rather have a unique username for my application.  Is this a good idea, or should I just turn on impersonation and impersonate each individual user? "

No, if you impersonate each individual user connection pooling will stop working as designed. It relies on the connection and userid (whether Integrated Windows user id or SQL Login) being the same across all connections.

Duncan Smart
Wednesday, April 2, 2003

By including only the tag <identity impersonate="true" /> in the web.config, and setting the IIS authentication for the app to Integrated Windows, the user's Windows user name will be used and authentication will be handled by Windows.

There is no need to insert the a username and password in this case.

Ian Lowe
Friday, April 4, 2003

If you use <identity impersonate="true" /> there are 2 issues you need to consider:

1) If your users are authenticated using Windows authentication then each user ends up with their own connection to the database; ie, connection pooling is not working.

2) If you are using anonymous authentication or Forms authentication then the connection is made using the ASPNET account. The account used is configured from machine.config - the problem being that *all* the web apps on the server will have to use that same account (after you've created the corresponding login in SQL server). We can't assume that our customers are going to allow us to touch machine.config to make such sweeping changes.

So I don't think impersonation is a good idea, and SQL's built-in authentication mechanism is still the best way of connecting.

Duncan Smart
Saturday, April 5, 2003

*  Recent Topics

*  Fog Creek Home