【问题标题】:Allowing External Users to Communicate with Internal service允许外部用户与内部服务通信
【发布时间】:2015-07-20 20:01:28
【问题描述】:

我在将内部用户可以访问的信息暴露给经常在我们内部网络之外旅行的用户时遇到问题。

现在的工作方式是我们有一个程序可以访问托管在面向公众的安全网站上的 WCF 服务。当用户使用我们的内部网络时,该服务运行良好。但是,一旦用户离开网络(比如去酒店),他们就会得到 401: not Authorized 错误。

有时有以下根本原因

  1. 使用客户端身份验证方案“匿名”未授权请求。收到的标头是“NTLM,协商”
  2. 系统无法联系域控制器来处理身份验证请求
  3. 此工作站与主域之间的信任关系失败。

有一个我不太喜欢的解决方法,即手动将凭据(域/用户名和密码)添加到 Windows 凭据管理器,直到清除凭据然后处理重新开始。发生这种情况时,用户可以在浏览器中导航到服务并在程序中成功使用它们。

这是我们用于 WCF 服务的绑定

     <basicHttpBinding>
    <binding name="secureHttpBinding" maxReceivedMessageSize="2147483647" maxBufferSize="2147483647" maxBufferPoolSize="2147483647">

      <security mode="Transport">

        <transport clientCredentialType="Windows" />

      </security>

    </binding>
  </basicHttpBinding>

似乎基于 Windows 凭据管理器修复,我们应该能够使用用户 Active Directory 帐户来管理此服务的身份验证。

我只是想知道是否可以部署一项服务,允许远程用户访问基于他们已成功登录到我们域的帐户。

【问题讨论】:

    标签: windows wcf authentication ssl active-directory


    【解决方案1】:

    将内部端点直接暴露给外部世界不是一个好习惯。您始终使用外部总线,因此您不需要打开任何防火墙端口。例如,您可以更好地使用 Azure 服务总线,它比允许直接连接到您的内部网络更安全可靠。

    将本地应用程序连接到云端

    服务总线中继通过允许本地 Web 服务投射公共端点,解决了本地应用程序与外部世界之间通信的挑战。然后系统可以访问这些网络服务,这些服务在地球上的任何地方继续在本地运行。

    http://azure.microsoft.com/en-us/services/service-bus/

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2023-02-09
      • 2018-06-30
      • 2021-09-09
      • 1970-01-01
      相关资源
      最近更新 更多