以下问题假设我们在WAS中托管与Asp.Net并行的WCF服务：
“与Asp.Net并行托管WCF时 - WCF托管 基础设施拦截WCF请求时 PostAuthenticateRequest事件被引发并且不返回处理 到ASP.NET HTTP管道。编码为拦截的模块 管道后期的请求不会拦截WCF 请求“。
“使用并排配置，WCF托管基础架构 拦截WCF消息并将它们从HTTP管道“
中路由出去
a）假设WAS收到WCF服务请求，将调用WCF的身份验证机制（ Windows ， MembershipProvider 或自定义身份验证）何时引发PostAuthenticateRequest事件，或者只有在将请求路由到HTTP管道之后，WCF才会对请求进行身份验证？换句话说，WCF的身份验证机制是否在IIS的处理管道之外工作？
b）如果WCF的身份验证机制在IIS处理管道之外工作，那么我假设 FormsAuthenticationModule 不涉及验证WCF客户端（假设服务使用表单身份验证）？
c）另外，如果WCF的身份验证机制在IIS处理管道之外工作，那么我假设必须为匿名身份验证配置IIS / WAS，即使服务是使用Windows身份验证的身份验证客户端吗？
d）如果WCF服务由IIS7托管（除了服务必须只使用通过HTTP协议进行通信的端点这一事实），上述问题的答案会有所不同吗？
谢谢
答案 0 :(得分：1)
我建议实施技术峰值项目。
您可以随时实施codeaccessattribute来保护您的操作合同。
您可以首先应用PrincipalPermission（内置），在Thread.CurrentPrincipal（wcf服务的构造函数）上设置IPrincipal 在IIS中托管时，您可以设置HttpContext.Current.User但是在您的情况下HttpContext将为null。要使用PrincipalPermission，您需要有自己的能力来创建/实现IPrincipal。
答案 1 :(得分：1)
我只能回答D部分和部分B，但这可能足以解决您要解决的问题：如果您在ASP.Net应用程序中托管WCF服务，则启用表单身份验证WCF服务中的ASP.Net兼容性。我们在Silverlight小程序中广泛使用此方法。
这是一个两步过程：
1）使用AspNetCompatibilityRequirements属性（下面的vb.net代码）装饰你的WCF服务实现类：
<AspNetCompatibilityRequirements(RequirementsMode:=AspNetCompatibilityRequirementsMode.Allowed)> _
2）将以下条目添加到web.config中的<system.servicemodel>部分：
<serviceHostingEnvironment aspNetCompatibilityEnabled="true" />