Wednesday, June 22, 2005

ASP.NET Apps within SharePoint

While designing a digital asset management system for one of my clients, I considered running the ASP.NET app within SharePoint by simply instructing SharePoint to exclude the path. This is a pretty good idea, if the app can live within the confines SharePoint imposes. Authentication & Session, for example, can't be controlled at the this level.

If your app needs to impersonate, the capabilities are limited. Setting impersonation in the identity element causes the Windows Identity to be IUSR_. Leaving impersonation off causes the Windows Identity to be that of the App Pool (NETWORK SERVICE in my case). In either case, the Page and Thread Principals are empty since the Directory Security setting in IIS allows anonymous. Changing the Dir Sec setting does as you'd expect -- the Page and Thread Principals are set appropriately, impersonation is set, etc. But, now the entire top-level SharePoint site requires authorization (no anonymous access).

ASP.NET Impersonation and Principals

Every now and then I write a simple app to remind myself of what the principals are for the various impersonate config options. Maybe in the future I'll remember to look here.

Assumptions:
  • VRoot requires authentication (anonymous disabled)
  • VRoot's App Pool identity using NETWORK SERVICE
  • "IEUser" is the end user
  • "ImpersonatedUser" is the user config'd in the identity element
















ScenarioPage
User
Thread
CurrentPrincipal
WindowsIdentity
impersonate=falseIEUserIEUserNETWORK SERVICE
impersonate=true;
userName not set
IEUserIEUserIEUser
impersonate=true;
userName set
IEUserIEUserImpersonatedUser

So, the identity of System.Security.Principal.WindowsIdentity is the only one that changes. Page.User should typically be used for IsInRole checks.