Is only WCF's inner process called channel binding?

I have a modular application that creates objects in separate AppDomains and communicates with them through WCF channels. I do not want anyone in my process to be able to connect to these pipes.

Suggestions?

<edit> I don't know much about deletion - would it be a terrible idea to write a transport that uses remote access under the hood? </edit>

+4
source share
3 answers

Sorry, I can be late ... but better late than never :) What you can do is share the object between your applications ... For example, create a random GUID in the first and send it to the second (serialization ...). then if both AppDomains know this auth token, you can do something like this:

/// <summary> /// Inspect client messages : add GUID in headers /// </summary> internal class CProcessAuthenticationClientInspector : IClientMessageInspector { #region IClientMessageInspector Membres public void AfterReceiveReply(ref System.ServiceModel.Channels.Message reply, object correlationState) { } public object BeforeSendRequest(ref System.ServiceModel.Channels.Message request, System.ServiceModel.IClientChannel channel) { request.Headers.Add(MessageHeader.CreateHeader("ProcessAuth", "http://schemas.YOURCOMPANY.com/YOURAPPID", CProcessAuthenticationBehavior._authToken)); return null; } #endregion } /// <summary> /// Inspect server messages : Check GUID /// </summary> internal class CProcessAuthenticationDispatchInspector : IDispatchMessageInspector { #region IDispatchMessageInspector Membres public object AfterReceiveRequest(ref Message request, System.ServiceModel.IClientChannel channel, System.ServiceModel.InstanceContext instanceContext) { Guid token = OperationContext.Current.IncomingMessageHeaders.GetHeader<Guid>("ProcessAuth", "http://schemas.YOURCOMPANY.com/YOURAPPID"); if (token != CProcessAuthenticationBehavior._authToken) throw new Exception("Invalid process"); return null; } public void BeforeSendReply(ref Message reply, object correlationState) { } #endregion } /// <summary> /// Add inspectors on both client and server messages /// </summary> public class CProcessAuthenticationBehavior : IEndpointBehavior { /// <summary> /// Authentification token known by both sides of the pipe /// </summary> internal static Guid _authToken = Guid.NewGuid(); #region IEndpointBehavior Membres public void AddBindingParameters(ServiceEndpoint endpoint, System.ServiceModel.Channels.BindingParameterCollection bindingParameters) { } public void ApplyClientBehavior(ServiceEndpoint endpoint, System.ServiceModel.Dispatcher.ClientRuntime clientRuntime) { clientRuntime.MessageInspectors.Add(new CProcessAuthenticationClientInspector()); } public void ApplyDispatchBehavior(ServiceEndpoint endpoint, System.ServiceModel.Dispatcher.EndpointDispatcher endpointDispatcher) { endpointDispatcher.DispatchRuntime.MessageInspectors.Add(new CProcessAuthenticationDispatchInspector()); } public void Validate(ServiceEndpoint endpoint) { } #endregion } 

And then you just need to add the behavior of your endpoint to your endpoint on both sides:

customer:

 ChannelFactory<TInterface> factory; factory = new ChannelFactory<TInterface>(BuildLocalBinding(), "net.pipe://localhost/foo"); factory.Endpoint.Behaviors.Add(new CProcessAuthenticationBehavior()); 

server:

 ServiceHost svcHost = new System.ServiceModel.ServiceHost(imlpementationType); svcHost.AddServiceEndpoint(interfaceType, binding, "net.pipe://localhost/foo"); svcHost.Description.Endpoints[0].Behaviors.Add(new CProcessAuthenticationBehavior()); 

Well ... this can be done in config, but I will let you dig :)

Hope this helps.

+2
source

You can add some security rules to your binding. They allow you to request authentication, sign content, and encrypt it, depending on your security needs.

See WCF Security Essentials on MSDN for more information.

+1
source

... netNamedPipeBinding, which provides cross-process communication on the same machine. Named pipes do not work machines ...

NetNamedPipeBinding will fulfill your goals.

NetNamedPipeBinding is optimized for sharing on a computer .

0
source

Source: https://habr.com/ru/post/1385203/


All Articles