Hi Daniel, We've started to work on this at http://www.dotnetremoting.cc/projects [open source .net remoting projects]. Some weeks ago, Jonathan Hawkins (the program manager for .NET Remoting) announced that they will probably release such a channel/sink combination to gotdotnet.com so we stopped our implementation right at the beginning. [well, Tomas has the SSPI wrapper and such]
But ... they didn't yet release it, so maybe we should start working on it again. Drop me a note if you're interested ;) -Ingo Author of "Advanced .NET Remoting" http://www.dotnetremoting.cc > -----Original Message----- > From: Daniel Pratt [mailto:[EMAIL PROTECTED]] > Sent: Friday, May 03, 2002 10:36 PM > To: [EMAIL PROTECTED] > Subject: [DOTNET] adding security features to remoting > > > Hi All, > > I know that remoting does not have any built-in > facilities for security. I've been thinking it would be an > interesting and informative pet project to try to incorporate > Windows security with a remoting channel. My > conceptualization of the solution: > > 1. Create a managed wrapper around the SSPI APIs. I found > a C++ lib (WSSPI) that should make this a little easier. On > the other hand, I'm not an experienced C++ programmer, so > this should still be fun :-) > > 2. Create a channel based on an existing channel. Maybe I > start with the Named Pipe Channel Sample. > > 3. When the client channel connects to the server channel... > a. ...do an NTLM-style handshake using SSPI to create > a context handle, then... > b. ...convert the context handle to a handle to an > access token, then... > c. ...put the access token into the channel data store. > > 4. When a message is processed, put the access token into > the logical call context. > > 5. Create a context utility class that has a > RemotePrincipal property that is a WindowsPrincipal object > created with the access token in the call context. > > Does this sound sensible/feasible? Am I making this too > hard? Thanks for any feedback. > > Regards, > Daniel Pratt > > You can read messages from the DOTNET archive, unsubscribe > from DOTNET, or > subscribe to other DevelopMentor lists at http://discuss.develop.com. > You can read messages from the DOTNET archive, unsubscribe from DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.