|
dev
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
Remoting: security and app.configHello, I have written a service (service A) in C# which is both a TCP server
for many clients and is also a client of another service (service B). For service A the TcpServerChannel is configured in the app.config file with secure=true which works fine. All the clients connect to this service using secure TcpClientConnections. For service B the TcpServerChannel is configured in the app.config file with secure=false. I cannot get service A to successfully connect to service B using a TcpClientChannel with no security. It seems that the TcpClientChannel on service A is configured to use security even though I specify that I do not want security on. Is it possible to configure security for the server channel and no security for the client channel? Can I do this in the app.config, or do I need to do it programmatically? Thanks, Hi pinnguy,
Thank you for posting. From your description, you're using .net remoting for communication between multiple applciations, include client UI based application and service applications. One of the client application will call a remote object from service A, and they're using secured channel, and service A will call another remote object from service B which does not use secured channel. However, you found the service A can not correctly get the remote object from service B, correct? When the service A get error, what's the detailed error message of that exception? Also, for such scenario, I'd suggest you try creating two simplified application (not service) and test the same behavior. Then, we can do further research against the simplified applications. Regards, Steven Cheng Microsoft Online Community Support ================================================== When responding to posts, please "Reply to Group" via your newsreader so that others may learn and benefit from your issue. ================================================== This posting is provided "AS IS" with no warranties, and confers no rights. Get Secure! www.microsoft.com/security (This posting is provided "AS IS", with no warranties, and confers no rights.)
Show quote
"Steven Cheng[MSFT]" wrote: Thanks Steven, you have correctly restated my configuration.> Hi pinnguy, > > Thank you for posting. > > From your description, you're using .net remoting for communication between > multiple applciations, include client UI based application and service > applications. One of the client application will call a remote object from > service A, and they're using secured channel, and service A will call > another remote object from service B which does not use secured channel. > However, you found the service A can not correctly get the remote object > from service B, correct? > > When the service A get error, what's the detailed error message of that > exception? Also, for such scenario, I'd suggest you try creating two > simplified application (not service) and test the same behavior. Then, we > can do further research against the simplified applications. > > Regards, > > Steven Cheng > Microsoft Online Community Support Here is the error and stack trace that occurs when service A trys to open a TCP client connection to service B: System.Net.Sockets.SocketException Reason=An existing connection was forcibly closed by the remote host StackTrace= Server stack trace: at System.Net.Security.NegoState.ProcessAuthentication(LazyAsyncResult lazyResult) at System.Net.Security.NegotiateStream.AuthenticateAsClient(NetworkCredential credential, String targetName, ProtectionLevel requiredProtectionLevel, TokenImpersonationLevel allowedImpersonationLevel) at System.Runtime.Remoting.Channels.Tcp.TcpClientTransportSink.CreateAuthenticatedStream(Stream netStream, String machinePortAndSid) at System.Runtime.Remoting.Channels.Tcp.TcpClientTransportSink.CreateSocketHandler(Socket socket, SocketCache socketCache, String machinePortAndSid) at System.Runtime.Remoting.Channels.SocketCache.CreateSocketHandler(Socket socket, String machineAndPort) at System.Runtime.Remoting.Channels.RemoteConnection.CreateNewSocket(EndPoint ipEndPoint) at System.Runtime.Remoting.Channels.RemoteConnection.CreateNewSocket() at System.Runtime.Remoting.Channels.SocketCache.GetSocket(String machinePortAndSid, Boolean openNew) at System.Runtime.Remoting.Channels.Tcp.TcpClientTransportSink.SendRequestWithRetry(IMessage msg, ITransportHeaders requestHeaders, Stream requestStream) at System.Runtime.Remoting.Channels.Tcp.TcpClientTransportSink.ProcessMessage(IMessage msg, ITransportHeaders requestHeaders, Stream requestStream, ITransportHeaders& responseHeaders, Stream& responseStream) at System.Runtime.Remoting.Channels.BinaryClientFormatterSink.SyncProcessMessage(IMessage msg) Here is the <channels> portion of the app.config file for service A: <channels> <channel ref="tcp" port="10000" secure="true" protectionLevel="EncryptAndSign" name="tcp server"> </channel> </channels> Here is some code snippets showing how service A attempts to create an unsecure tcp client channel to service B: IDictionary connInfo = new Hashtable(); connInfo["protectionLevel"] = "None"; connInfo["secure"] = "False"; connInfo["tokenImpersonationLevel"] = "None"; IChannel channel = new TcpClientChannel(connInfo,null); try { ChannelServices.RegisterChannel(channel,true); } catch (RemotingException re) { // ignore this, it happens when channels is already registered. } // agntPrxyUrl - url to remoting obj in service B ITransferAgent agent = (ITransferAgent)Activator.GetObject( typeof(ITransferAgent),agntPrxyUrl); // Throw SocketException here if tcp server channel is secure. // Works just fine if tcp server channel is secure="false" AgentStatus as = agent.Status; Thanks for your response pinnguy,
I think the problem is still on the secure setting of the channel you registered. I've performed some local test (through 3 console apps), and we are able to make the intermediate application serve both client and server remoting through two channels (client and server) with different secure setting. So let's still focus on your "service A"(which is the intermediate app in your case, correct?). From the code you provided, I saw that you use the following code to initalize the no-secure channel: ======================== Dictionary connInfo = new Hashtable(); connInfo["protectionLevel"] = "None"; connInfo["secure"] = "False"; connInfo["tokenImpersonationLevel"] = "None"; IChannel channel = new TcpClientChannel(connInfo,null); try { ChannelServices.RegisterChannel(channel,true); } =========================== The ChannelServices.RegisterChannel Method's second parameter is just used to set the "secure" setting, and it'll always override the setting you put in the Construnctor's properties collection. So you need to pass "false" into the "RegisterChannel" method. Here is my intermediate applicatino's channel initialize code: ================================= static void Init() { Console.WriteLine("Init........................"); InitClient(); InitServer(); } static void InitClient() { Console.WriteLine("InitClient............................"); IDictionary props = new Hashtable(); props["name"] = "tcpCC1"; TcpClientChannel clientChannel1 = new TcpClientChannel(props, null); // do not secure the channel ChannelServices.RegisterChannel(clientChannel1, false); } static void InitServer() { Console.WriteLine("InitServer............................."); IDictionary properties = new Hashtable(); properties["name"] = "tcpSC"; properties.Add("port", 7777); TcpServerChannel serverChannel = new TcpServerChannel(properties, null); //secure the channel ChannelServices.RegisterChannel(serverChannel,true); ); } ================================ Hope this helps. Regards, Steven Cheng Microsoft Online Community Support ================================================== When responding to posts, please "Reply to Group" via your newsreader so that others may learn and benefit from your issue. ================================================== This posting is provided "AS IS" with no warranties, and confers no rights. Get Secure! www.microsoft.com/security (This posting is provided "AS IS", with no warranties, and confers no rights.) "Steven Cheng[MSFT]" wrote: I made a mistake in the pseudo code I posted. I actually do have the secure > I think the problem is still on the secure setting of the channel you > registered. setting set to false. But it does not make any difference, I still get the error. I did figure out to fix it though. The problem is orginating in the channel template for ref="tcp" in the app.config file. When this template is used, an instance of a TcpChannel is created and registered when RemotingConfiguration.Configure is called. Since I specified secure="true" for this channel, the same settings where also used by my tcp client channels. So to get around this, instead of using the ref="tcp" template, I directly specify the type I want using type property. So my app.config channel element looks like this: <channel type="System.Runtime.Remoting.Channels.Tcp.TcpServerChannel, system.runtime.remoting, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" port="10000" secure="true" protectionLevel="EncryptAndSign" name="tcpServer"/> Now it works! I can have a secure server channel and an unsecure client channel. Thanks for your response pinnguy,
Yes, you're right. As for TcpChannel or HttpChannel class, they both implement IChannelSender and IChannelReceiver, so the runtime will pickup the one for both server and client component. Your approach about manually reference the TcpserverChannel and TcpClientChannel is reasonable. Also, in my test app, I do all the channel registering programmatically (not use config file), this also works. Regards, Steven Cheng Microsoft Online Community Support ================================================== When responding to posts, please "Reply to Group" via your newsreader so that others may learn and benefit from your issue. ================================================== This posting is provided "AS IS" with no warranties, and confers no rights. Get Secure! www.microsoft.com/security (This posting is provided "AS IS", with no warranties, and confers no rights.) |
|||||||||||||||||||||||