The "Important" note above the web service sample hints at the security delimma when following the Web Service sample above... if you put the Web Service which executes SSIS packages in an Application pool, it use the Application Pool's Identity to control which account the package executes under, but the caller's context may be used only in a limited fashion to LOAD the package if impersonation is enabled in ASP.Net, but it won't necessary EXECUTE the package under that same impersonated context.
http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1235663&SiteId=1
http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=927084&SiteID=1
This due to the way that ASP.Net impersonation only works for the caller's first thread, and not additional worker threads which the caller's code spawns (ie. behind the scenes SSIS application and package use multiple threads). Wonder if we could launch DTExec.exe from a web service in a separate process and do more customized impersonation that way.
ASP.NET Impersonation: http://msdn2.microsoft.com/en-US/library/aa292118(VS.71).aspx
Process.Start method: http://msdn2.microsoft.com/en-us/library/e8zac0ca.aspx
Like the code example in that msdn reference, I can use Process.Start() to run DTExec.exe under a string of the account and password. Set up a Process object (part of System.Diagnostics) and set a StartInfo object (Process.StartInfo) to provide the strings of the file name, arguments, account, domain, and password, and then call Process.Start using that StartInfo (part of System.Security) to launch DTExec.exe under my hard coded domain\username and password. It was tricky to get the SecureString password typed in using .AppendChar("a") one letter at a time. But the problem is you can't get the password of the caller to do this method - you can only hard code it, or ask the user to type in their password into a the web form and submit the call that way using their name and password. That's still limiting because the user has to type in all the info, and ASP.Net doesn't just find out this information with integrated security.
From all the web documentation and blogs I read, ASP.Net Impersonation cannot natively emulate the caller's security context to launch a child process under that caller's context, without jumping through hoops... This KB explains the hoops.
How to spawn a process that runs under the context of the impersonated user in Microsoft ASP.NET pages http://support.microsoft.com/kb/889251
Using that approach, you could call CreateProcessAsUser, impersonate the caller of the web app and launch DTExec.exe on the server side, calling any package you wanted. Seems pretty interesting approach, but definately don't want to leave the hole open to launch any program for this scenario - I'll just hard code DTExec.exe into the path of the command line, and let the user type in the package name.