views:

125

answers:

2

I'm sure it's a requirement many developers have faced before: business needs an audit trail to know who is performing actions in their system.

Regardless of how you choose store the audited information, the core of this problem is how to identify the current user.

I want to write components, ranging from small domain model classes to service components, all which can safely be called from any of the following host applications:

  • A Windows desktop application.
  • An ASP.NET website hosted in IIS.
  • A WCF service hosted in IIS.
  • A WCF service hosted in a Windows service.

Given the range of technologies, the various authentication models and having to account for the concept of an "anonymous" user, I'm not clear on a strategy to use to get the identity of whoever invoked my component in a centralised fashion.

Can any of you smart folk suggest an approach to tackle this?

+4  A: 

The best approach, using the most current techniques, is probably to use Windows Identity Foundation.

WIF is designed to handle user identity issues across multiple technologies using .NET.

Reed Copsey
WIF looks really interesting, but I see it actually complicating my problem by providing another source of identity information I may have to account for!
Programming Hero
Except that it consolidates everything, so you have one source you can use across all of your host applications. You could consolidate everything into one lib. very easily using WIF.
Reed Copsey
Perhaps I've misunderstood what WIF can achieve. Can you provide an example of how I might use WIF to allow me to use a theoretical component in, say, a Windows desktop application and an ASP.NET application?
Programming Hero
Reed Copsey
Thanks for your assistance. Am I right in thinking WIF is effectively an infrastructure change to replace specific identity sources with a generic claims-based system? I'm not sure I can justify an infrastructure change for the purposes of easier auditing, heh.
Programming Hero
Yeah, it really is. Although it's built upon the standard windows federated identity infrastructure, so if you're using AD, it pretty much works without any changes.
Reed Copsey
+1  A: 

I would generally require that applications set Thread.CurrentPrincipal to a principal whose identity represents the current user. This can be done at application startup (using WindowsIdentity.GetCurrent()) in a client (WinForms or Console) app, from HttpContext.Current.User or Roles.GetCurrentUser() in an ASP.NET or WCF application hosted in IIS, etc.

Then in the lower level components you simply use Thread.CurrentPrincipal.Identity for auditing.

EDIT (In response to comment) - note that Thread.CurrentPrincipal.Identity has nothing to do with the security context of the thread: this is represented by the WindowsIdentity and can be retrieved using WindowsIdentity.GetCurrent and changed using WindowsIdentity.Impersonate.

Joe
Will this have any impact on the security context of the thread?
Programming Hero