Integrated Security and impersonation

The use of impersonation in Smartsite affects the way files are accessed by IIS. If impersonation is enabled, extra NT users come into play and for these NT users, different ACL rules may apply. Different ACL rules can result in some users having access to certain files and folders, while other do not. Access to the WWW folder is particularly interesting because in some scenarios you can use this feature to grant or deny certain users access to files or folders. This article describes four common scenarios and their side effects.

Scenario 1: No Integrated Security and no impersonation

In this scenarion, the only NT users that is used is the identity of the Application Pool, most likely the Network Service. Since all Smartsite users are using the identity of the Application Pool, you need to make sure that the Network Service has sufficient access to your file system. However, because all Smartsite users use a single file, you cannot use ACL's to grant or deny access for special users.

Scenario 2: Integrated Security and no impersonation

This is scenario, IIS renders each request using the credentials of the user that performs the request. Whenever IIS or Asp.Net needs to access a file on disk, the Windows kernel tests if the current user (i.e. the user that performs the request) has sufficient access to that file. If so, the user may download that file, if not an error will be raised. This scenario allows you to use NTFS security to grant or deny file access.

Scenario 3: No Integrated Security and impersonation

Because you are using impersonation, Smartsite will make sure that each request that is performed by a user, is performed using the credentials of the NT user of the security profile that belongs to that user. This way, all the users in a certain role all access the file on disk using the same security profile and thus using the NT user. This allows you to set ACLs for that NT user by which means you can grant or deny access for an entire group of users. When using impersonation it is not possible to grant or deny access for individual users. 

Scenario 4: Integrated Security and impersonation

This scenario works pretty much the same as scenario 3. IIS will use the identity of the user that performs the request but that identity will be overruled by the impersonation in Smartsite. From that point on this scenario behaves the same as scenario 3. Note that in this scenario the benefits of Integrated Security (i.e. running under the users that performs the request) are limited because the identity is overruled by Smartsite's impersonation. You still benefit from having a single user administration in Active Directory.