I have a WCF application that is using Windows Authentication. So a Windows Principal object is what I will find in the System.Threading.Thread.CurrentPrincipal() property. That's is all fine. However, I also have a custom principal object that is used for finer grained authorizations and auditing. This is a domain user, not a windows user. I really need both and am looking for a place to store the custom user on the service side so that all the code that runs on the service, down through Business and Data layers, can access this user.
The communication between client and server is handled by a custom behavior and message inspector. When calling the service from the client (ASP.NET Web Application), this gets the current user from session and serializes it to a custom header on the service call. On the service side it then strips the principal out of the header and puts the custom principal here:
OperationContext.Current.ServiceSecurityContext.AuthorizationContext.Properties("CurrentDomainUser")
So, questions to validate this approach:
- Is this a valid approach to storage of a custom principal on the service. Keeping in mind I want to Windows Authentication to stay in place.
- Is this "best practice"? Or is there a better way?
- Any traps or pitfalls to watch for with this approach?
Thanks for the input.