Application pool identity or Impersonation

(A question of similar vein has been asked before but both the question and the accepted answer do not provide the detail I am looking for)

With the intention of running an asmx web service under a dedicated domain account what are the usage scenarios and/or pros and cons开发者_运维问答 of using an Application Pool with the identity of the domain account versus Impersonation?

We have 3 small internal web services that run under relatively low load and we would like to switch them to running under their own domain accounts (for the purpose of integrated security with SQL Server etc). I appear to have the choice of creating dedicated app pools for each application, or having a single app pool for all the applications and using impersonation in each.

I understand app pools provide worker process isolation and there are considerations for performance when using impersonation, however those aside what else would dictate the correct option?

Typically, you will choose different identity for worker process (or do ASP.NET impersonation) because there is need to access local/network resources that needs specific permissions. Obvious dis-advantage is that your application code may run under more permissions than it may need and thereby increasing the vulnerability against malicious attacks.

ASP.NET impersonation would have more overhead because user context needs be switched for each request. I will suggest to go with separate app pool approach - only disadvantage with app pool approach is that you have process for each one of them and so there will be overhead (from OS perspective) for each process. If your applications are smaller and don't have strong memory demands then this should not be an issue,

If you want your web services to connect to SQL via Windows authentication, you will almost certainly want to set up each application with the dedicated app pool option. This requires the least amount of setup and administration.

If you go the impersonation route, you'll need to account for the "two-hop" issue. When a user calls a web service that is using impersonation, the web service can access local resources, as that user. However, if the web service tries to connect to a non-local resource (e.g., a database running on a separate server), the result will be an authentication error. The reason is that NTLM prevents your credentials from making more than one "hop". To workaround this, you would need to use Kerberos delegation. Delegation isn't difficult to set up, but it does require Domain Admin privileges, which can make things difficult in some corporate environments.

In addition, using impersonation means that you need to manage database permissions for each user that may visit your web service. The combination of database roles and AD groups will go a long way in simplifying this, but it's an extra administrative step that you may not wish to conduct. It's also a possible security risk, as certain users may end up with privileges that are greater than your web services are anticipating.

Impersonation is useful when you need a common end user experience with other Windows services that are based on Windows security.

For example, Microsoft SharePoint servers use impersonation because you can access SharePoint document libraries with web browsers and with the standard Windows shares UI (connect / disconnect to a network share, based on the SMB protocol). To ensure security is consistent between the two, in this case, you need impersonation.

Other than this kind of scenario, impersonation is most of the time not useful (but can cost a lot in terms of scalability)

Application pool pros:

You don't have to be a .Net programmer to understand what's going on.

The security aspect leaves the domain of the programmer and falls under the remit of infrastructure

Easy to change through IIS with proper saftey checks that the username is correct when setting up the app pool. I.e. It won't let you enter an incorrect username.

Impersonation pros:

1. Privileges can be documented and traced back through changes to configuration through source control history if configuration files are stored there.

Impersonation cons:

1. To change the user, you need to be familiar with .Net configuration rather than just setting up a website

Not sure I can think of much else.

My gut says to go with different application pools for each of the websites but it's your party.

I would advise you to check the following page for security details...

https://www.attosol.com/sample-aspx-page-to-show-security-details-in-asp-net/

Once you are done with this, you will see "precisely" how impersonation changes the identity.