WCF 授权策略：模拟问题
我有以下情况（概要）：
授权Web服务
该服务被调用并验证（通过执行给定的业务逻辑）用户是否有效。
定制业务网络服务
这是为业务应用程序创建的一些 Web 服务，它在内部调用“授权 Web 服务”以验证调用业务 Web 服务的帐户。
我通过在“自定义业务 Web 服务”中使用 WCF 服务授权来实现此逻辑。基本上我配置了
<serviceAuthorization principalPermissionMode="Custom">
<authorizationPolicies>
<add policyType="MyCompany.Authorization.WCF.AuthorizationPolicy, MyCompany.AuthorizationDll"/>
</authorizationPolicies>
</serviceAuthorization>
AuthorizationPolicy 在内部调用“Authorization Webservice”。
问题
问题是我需要模拟“自定义业务 Web 服务”的调用者。客户端标识是正确的，但 WindowsIdentity 是应用程序池用户的标识。
请注意，如果我在 AuthorizationPolicy 的 Evaluate(... ） 方法。
（显然，我使用 Windows 身份验证凭据使用传输级安全性）
任何人都可以提示我如何在输入 IAuthorizationPolicy.Evaluate(...) 方法之前模拟调用者？
I have the following situation (outline):
Authorization Webservice
This service gets called and verifies (by executing the given business logic) whether a user is valid or not.
Custom Business Webservice
This is some webservice created for a business app, that internally calls the "Authorization Webservice" in order to verify the account which called the business webservice.
I realized this logic by making use of WCF service authorization in my "Custom Business Webservice". Basically I configured
<serviceAuthorization principalPermissionMode="Custom">
<authorizationPolicies>
<add policyType="MyCompany.Authorization.WCF.AuthorizationPolicy, MyCompany.AuthorizationDll"/>
</authorizationPolicies>
</serviceAuthorization>
The AuthorizationPolicy internally invokes the "Authorization Webservice".
The Problem
The problem is that I need to impersonate the caller of my "Custom Business Webservice". The client identity is the correct one, however the WindowsIdentity is that of the application pool user.
Note, impersonation works within the service itself if I use [OperationBehavior(Impersonation = ImpersonationOption.Required)] but it does not within the AuthorizationPolicy's Evaluate(...) method.
(I use Transport level security using windows authentication credentials, obviously)
Anyone has any hints on how I can impersonate the caller prior to entering the IAuthorizationPolicy.Evaluate(...) method??
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
回答我自己的问题总是感觉有点奇怪，但为了与其他人分享我得到的东西，我将在这里发布“解决方案”。
我会尽量简明扼要：
正如我已经提到的，通过放置
[OperationBehavior(Impersonation = ImpersonationOption.Required)].因此，调用我的自定义 Web 服务来检索主体作为我的服务操作中的第一个语句始终有效。然而我不喜欢这种方法。作为替代方案，我尝试在 WCF 服务操作的调用链中找到模拟最终起作用的最新可能点。这是我找到
OperationInvoker的地方。下图说明了在调用到达实际操作之前完成的调度顺序（取自 此处）：
参数检查为时过早，模拟尚未起作用，但幸运的是它在操作调用器中起作用。因此，通过编写自定义操作调用程序并将所有内容包装到自定义操作行为属性中，我能够优雅地解决问题。
有关我写的博客文章的更多信息< /a>.
It always again feels a bit strange, answering to my own questions, but for the sake of sharing what I got with others I'm going to post the "solution" here.
I'll try to make it short:
As I already mentioned, impersonating the caller within the webservice operation worked by placing the
[OperationBehavior(Impersonation = ImpersonationOption.Required)]. So calling my custom webservice for retrieving the principal as the first statement in my service operation would always work. I didn't like that approach however.As an alternative I tried to find the latest possible point in the call chain of a WCF service operation where the impersonation finally worked. This is where I found the
OperationInvoker.The following diagram illustrates the sequence of dispatchings that are done before the call arrives at the actual operation (taken from here):
Parameter Inspection was too early, impersonation didn't yet work, but it luckily worked in the Operation Invoker. So by writing a custom operation invoker and wrapping everything into a custom operation behavior attribute I was able to elegantly solve the problem.
More info on an according blog post I wrote.