This post originated from an RSS feed registered with .NET Buzz
by Robert Hurlbut.
Original Post: Remoting and Security Updates
Feed Title: Robert Hurlbut's .Net Blog
Feed URL: http://www.asp.net/err404.htm?aspxerrorpath=/rhurlbut/Rss.aspx
Feed Description: Development with .Net, Rotor, Distributed Architectures, Security, Extreme Programming, and Databases
Over this past weekend, I took some time to expand my understanding and knowledge of other areas in .Net (besides EnterpriseServices, Security, Rotor, etc.) and was again looking at .Net Remoting. There are some good resources out there, but two of the best I have found are these: Distributed .Net Programming in C# by Tom Barnaby (for an introduction to .Net Remoting) and Advanced .Net Remoting by Ingo Rammer.
When I looked at .Net Remoting last November, I was concerned with Code Access Security (CAS) working across machines. I was also concerned about securing the Remoting transport when communicating across boxes. I just noticed this morning that a couple of older articles on this topic:
were updated January, 2004. According to the first article, here is what has been updated:
Note This is an update to the original article published in the summer of 2002. This update was mostly done to provide a version of the sample that works with the .NET Framework version 1.1. However, additional features have been added. Mutual authentication is now supported for Kerberos and the Identify flag is now supported for NTLM and Kerberos.
Some implementation details have also been changed in the sample. All classes now implement IDisposable where appropriate, allowing resources to be collected more aggressively than before. This is important for the authentication channel sinks which may run for long periods of time under high load.
As far as this article is concerned, the only significant change is to the section on Kerberos. Additional text has been added to explain the User2User sub-protocol which is now standard on the Microsoft Windows XP and Windows Server 2003 Kerberos implementations.
And from the second article:
The Microsoft.Samples.Runtime.Remoting.Security assembly has been rewritten. The relatively monolithic implementation in the first version has been replaced with a more granular design that's easier to understand. The channel sinks now feature a client and server state machine which manage the authentication handshake.
Impersonation no longer happens automatically on the server side. Instead, the developer of the remote object now has full control over impersonation by calling Thread.CurrentPrincipal.Identity.Impersonate().
The security sinks now always set a Principal on the thread calling the remote object. This allows the object implementer to take advantage of declarative security regardless of whether they explicitly inject a custom principal themselves.
These articles are definitely worth looking at as examples of securing the Remoting channels.
Previous Topic
