Impersonation is only important to access resources outside the application like files and directories on the network and external assemblies and business logic that implements security policies. So Impersonation has no importance in terms of accessing and using the application itself.
thank you
Did I understand Impersonation correctly:
Renis Cerga
Both of your scenarios can use WindowsIdentity (and the group membership). Impersonation is the act of changing the effective userId to something else, so impersonation can affect (but is not normally used for) both of those situations:
JoshKorn
Do u know what is usually used to implement thos 2 scenarios I just described. I ve seen those functionnalities in an application and I was wondering what they use to do that.
Thank you.
johnvarney
when u say:use the WindowsIdentity in your code to determine access to various functionality you have written.
Are you also talking about when some applications only allow managers to perform some tasks including even clicking on a menu or a toolbar button or a click button item while those same controls are disabled for other employees.
Or when the same toolbar buttons or menu items can be enabled for a department while they re disabled for another depatment. Do we do that using impersonation and security as well, or how do we do that
Thanks a lot.
Tom_Tregenna
That is basically true, unless you want to use the WindowsIdentity in your code to determine access to various functionality you have written.
Remember however, that many things most applications use can be affected by impersonation: reading/creating a file, querying a database that uses NT authentication, starting/stopping a service - even reading a registry value.
So yes, you have it right - but the things your application does may be affected by impersonation.