ASP.Net WCF 服务的 Thread.CurrentPrincipal 被联邦 (WIF) 环境中的某些拦截器丢弃

Question

我有一个托管在 IIS (.svc) 中的每次调用 WCF 服务。在服务的构造函数中，我根据 本文。在本例中，HttpContext.Current.User 的类型为 Microsoft.IdentityModel.Claims.ClaimsPrincipal，并且具有从我的自定义被动 STS 发回的声明。

但是，一旦我进入服务操作并检查 Thread.CurrentPrincipal，虽然该对象仍然是 Microsoft.IdentityModel.Claims.ClaimsIdentity 类型，但该对象本身是不再与 HttpContext.Current.User 相同（Thread.CurrentPrincipal.Identity 上的 IsAuthenticated = false、AuthenticationType = "" 且 Name 为 null），而这些值都是仍然正确填写HttpContext.Current.User。这告诉我，某些东西正在拦截对操作的调用，并错误地将当前主体更改为某些通用的、空的、未经身份验证的声明主体。

我检查了构造函数和操作中的线程 ID，它在两个地方都是相同的，并在从 HttpContext.Current.User< 分配后立即窗口中评估 Thread.CurrentPrincipal /em> 显示在构造函数中正确设置了线程标识，因此构造函数和方法之间肯定正在执行某些操作，并且某些操作正在更改我的 Thread.CurrentPrincipal。

有人知道这是怎么回事吗？我该如何防止/修复这种行为？

Answer 1

我刚刚遇到了类似的问题。我在 WCF 服务的构造函数中设置了自定义主体。当我离开构造函数并进入我调用的方法时，thread.currentprincipal 被空的覆盖。我通过添加以下行为解决了这个问题：

<serviceAuthorization principalPermissionMode="None"></serviceAuthorization>

这对我来说效果很好。

Answer 2

为 WIF 联合配置服务时，您调用

FederatedServiceCredentials.ConfigureServiceHost(this);

此调用的部分功能是在服务主机上设置 IdentityModelServiceAuthorizationManager 类型的自定义 ServiceAuthorizationManager。此授权管理器似乎在实例的激活（构造）和操作的执行之间被调用，并且它用 IClaimsPrincipal 的实例覆盖 Thread.CurrentPrincipal，但它似乎没有意识到它正在 ASP.NET 兼容模式下运行，因此它不会从 HttpContext.Current.User 中提取主体。

我能够通过从 IdentityModelServiceAuthorizationManager 派生并重写 CheckAccess 方法来绕过此行为，如下所示：

public class CustomAuthorizationManager : IdentityModelServiceAuthorizationManager
{
    public override bool CheckAccess(System.ServiceModel.OperationContext operationContext, ref System.ServiceModel.Channels.Message message)
    {
        var result = base.CheckAccess(operationContext, ref message);

        var properties = operationContext.ServiceSecurityContext.AuthorizationContext.Properties;
        properties["Principal"] = System.Web.HttpContext.Current.User;

        return result;
    }
}

然后将其应用到服务主机，如下所示：

protected override void InitializeRuntime()
{
    FederatedServiceCredentials.ConfigureServiceHost(this);
    this.Authorization.ServiceAuthorizationManager = new CustomAuthorizationManager();
    base.InitializeRuntime();
}

现在，当我输入我的服务操作时，我在 Thread.CurrentPrincipal 上拥有正确的 IClaimsPrincipal，因此声明式 PrincipalPermission 现在可以按预期工作。

Answer 3

调用的配置设置FederatedServiceCredentials.ConfigureServiceHost(this);

如下
在 system.serviceModel 中添加以下内容，然后

<extensions>
      <behaviorExtensions>
        <add name="federatedServiceHostConfiguration" type="Microsoft.IdentityModel.Configuration.ConfigureServiceHostBehaviorExtensionElement, Microsoft.IdentityModel, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>
      </behaviorExtensions>
    </extensions>

添加以下行

<behavior name="serviceBehavior">
          <federatedServiceHostConfiguration name="MyService" />

Answer 4

我的猜测是没有任何东西拦截呼叫。 CurrentPrincipal 要么在您检查时重置，要么您处于不同的线程中。

分配给 CurrentPrincipal 后立即检查它，您应该看到正确的值。