2011-12-07 12 views
4

私は、別々のAppDomainsで物をインスタンス化し、WCFパイプでそれらと通信するモジュラーアプリケーションを持っています。私は自分のプロセスの外の誰もがこれらのパイプに接続できるようにしたくありません。インプロセスのみのWCF名前付きパイプ通信ですか?

提案?

<編集>リモーティングに関することはよくわかりません - リモーティングをフードの下で使用するトランスポートを書くのはひどい考えですか? </edit >

+0

[NullTransport](http://www.codeproject.com/KB/WCF/NullTransportForWCF.aspx)を試すことはできますが、それは同じかもしれません。AppDomain- –

+0

ええ、それは同じAppDomainです。 –

+0

名前付きパイプはローカルマシン上でのみ動作します。そのマシンの他のアプリがあなたのサービスにアクセスしようとしますか? –

答えて

2

申し訳ありませんが遅くなる可能性があります。遅くはありません:) あなたのAppDomains間でオブジェクトを共有することができます... たとえば、最初のGUIDをランダムに作成して2番目のもの(シリアル化...)。

/// <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 
} 

そしてあなただけの両側にエンドポイントにエンドポイント動作を追加する必要があります:

クライアント:

両方のAppDomainが、これはトークンのauth知っていれば そして、あなたはこのような何かを行うことができます
ChannelFactory<TInterface> factory; 
factory = new ChannelFactory<TInterface>(BuildLocalBinding(), "net.pipe://localhost/foo"); 
factory.Endpoint.Behaviors.Add(new CProcessAuthenticationBehavior()); 

サーバー:

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

うーん...これであってもよいです設定で行われますが、私はあなたに掘りましょう:)

これは役立ちます。

+0

私はこれを実装する必要はありませんでしたが、私が今知っていることを知って、中央のappdomainに鍵が設定されている間に鍵を渡して認証することは間違いなく機能します。 –

1

バインディングにセキュリティ動作を追加できます。セキュリティのニーズに応じて、認証を要求し、コンテンツに署名し、暗号化することができます。

詳細については、MSDNのWCF Security Fundamentalsを参照してください。

+0

あなたはもっと具体的になることができますか?私はWCFでこれらのことがどのように機能するのか、それがどのようにして一般的なセキュリティを確保するのかを理解していますが、具体的な目標はどのように達成できますか? –

0

... netNamedPipeBindingバインディングは、同一マシン上でプロセス間で 通信を提供します。名前付きパイプは マシンでは機能しません。

NetNamedPipeBindingは目標を達成します。

NetNamedPipeBinding is optimized for on-machine通信。

+0

名前付きパイプはローカルマシンにのみ制限されていますか?別のマシンを経由してパイプを介してしか通信しないサービスを呼び出すことはできません。 –

+0

@Terry Donaghe:はい、そうです、私はtcp ..... shudderでプロキシされた名前付きパイプを使用していた時代遅れのことを考えていました。私はそれに応じて私の答えを更新します。 – Brook

+0

私は今NetNamedPipeBindingsを使用していますが、それらは同じマシン上のユーザーにはまだ開いています。そして、登録されたパイプのURIが発見可能であると私は思う。私はそれがセキュリティ上の懸念事項ではないと考えていますが、可能であればそれを使って何かしたいと思います。 –

関連する問題