限制对内部WCF服务的访问

我们在IIS上的一个asp.net应用程序中托管了几个WCF服务。我们正在获得越来越多的用于内部通信的服务（在我们自己的系统之间，客户端可以位于同一台服务器上或其他服务器上）。现在我们需要通过一些手段来保证这些服务。限制对内部WCF服务的访问

总之：目的是阻止其他人拨打我们的服务。只有在我们控制下的应用程序应该能够与这些服务进行通信

我们目前的想法：我们已经启用SSL，并且我们拥有服务器的公共证书。我们目前的计划是通过使用clientCredentialType =“UserName”来启用安全性，我们拥有一个自定义验证器，它可以根据我们定义的用户名/密码（很像API密钥）进行简单检查。

问题1：有没有更好的方法？情景听起来很简单，我觉得我们缺少一些明显的解决方案。

问题2：如果我们这样做，SSL证书已经足够了，或者我们必须创建任何其他证书？

某些上下文：.net 4，IIS 7，我们有权访问服务器。客户端/服务可能位于不同的服务器上。

更新1：客户端可能位于完全不同的网络上。我们还有其他一些托管在其他系统的系统也需要能够调用这些服务。

据我了解你的情况你有你的网络/ Windows域中的所有服务器/服务，不是吗？在这种情况下，我不会使用UserName身份验证。坚持与Windows安全和HTTPS。

要限制对您的服务的访问，您有几个选项都基于Windows帐户用于运行允许您的内部服务的客户端。分配这些客户帐户域组之后，你可以：基于

用户标准.NET角色的安全PrincipalPermission或PrincipalPermissionAttribute。这有缺点，您必须硬编码授权到您的服务。只有来自已定义窗口组的用户将能够访问该服务
前一种方法可能有希望（未经WCF测试，但可与ASP.NET协同工作）与ASP.NET角色提供者一起使用。在这种情况下，您可以在权限中使用自定义非Windows角色，并使用AutorizationStoreRoleProvider（AzMan）将域用户或域组映射到您的自定义角色。同样它至少需要硬编码自定义角色的权限。
How to use Authorization manager with ASP.NET 2.0
How to use ASP.NET Role provider in WCF
创建自定义ServiceAuthorizationManager在那里你会使用索赔窗口作用，对用户进行授权。这种方法的优点是您可以通过配置添加授权管理器，因此您不必触摸任何服务代码。
How to create custom AuthorizationManager for WCF service

2011-06-15 08:26:20

+1对于一个很好的答案。不幸的是，我的问题有点不清楚。某些客户端可能位于其他网络上。也许我没有把它称为“内部”，但我找不到更好的词。我用这个信息更新了这个问题。 – 2011-06-15 08:45:42

在这种情况下'UserName'是必需的，您仍然可以将其与自定义授权管理器或角色提供程序结合使用。 – 2011-06-15 08:48:25

即使其他网络上的客户端也可以使用Windows帐户进行身份验证，但您必须使用基本身份验证。 – 2011-06-15 09:51:04

回答