4

IIS (.svc) でホストされている呼び出しごとの WCF サービスがあります。サービスのコンストラクターで、この記事に従ってThread.CurrentPrincipal = HttpContext.Current.Userを設定しました。この場合、HttpContext.Current.UserはMicrosoft.IdentityModel.Claims.ClaimsPrincipal型であり、カスタム パッシブ STS から送り返されたクレームを持っています。

ただし、サービス操作に入ってThread.CurrentPrincipalを調べるとすぐに、このオブジェクトはまだMicrosoft.IdentityModel.Claims.ClaimsIdentity型ですが、オブジェクト自体はHttpContext.Current.Userと同じではなくなります( IsAuthenticated = false 、 AuthenticationType = "" 、および Name が Thread.CurrentPrincipal.Identity で null である場合)、これらの値はすべてHttpContext.Current.Userで正しく入力されます。これは、何かが操作への呼び出しをインターセプトし、現在のプリンシパルを一般的な、空の、認証されていないクレーム プリンシパルに誤って変更していることを示しています。

コンストラクターと操作でスレッド ID を確認しましたが、両方の場所で同じであり、HttpContext.Current.Userから割り当てた後、即時ウィンドウでThread.CurrentPrincipalを評価すると、スレッド ID が正しく設定されていることがわかります。コンストラクターなので、コンストラクターとメソッドの間で何かが確実に実行されており、その何かが私のThread.CurrentPrincipalを変更しています。

誰がこれをしているのか、どうすればこの動作を防止/修正できるのか分かりますか?

4

4 に答える 4

6

私はちょうど同様の問題に遭遇しました。WCF サービスのコンストラクターでカスタム プリンシパルを設定しました。コンストラクターを離れ、呼び出したメソッドに入ると、thread.currentprincipal が空のものによってオーバーライドされました。次の動作を追加することでこれを解決しました。

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

これは私にとってはうまくいきました。

于 2010-08-19T12:31:31.947 に答える
3

WIF フェデレーションのサービスを構成するときは、

FederatedServiceCredentials.ConfigureServiceHost(this);

この呼び出しが行うことの一部は、サービス ホストでタイプIdentityModelServiceAuthorizationManagerのカスタムServiceAuthorizationManagerをセットアップすることです。この承認マネージャーは、インスタンスのアクティブ化 (構築) と操作の実行の間に呼び出されるように見え、 Thread.CurrentPrincipal を IClaimsPrincipalのインスタンスで上書きしますが、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が期待どおりに機能するようになりました。

于 2009-12-22T09:00:21.170 に答える
1

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" />
于 2010-03-29T07:13:32.730 に答える
0

私の推測では、通話を傍受しているものは何もありません。CurrentPrincipal は、調べているときまでにリセットされているか、別のスレッドにいます。

割り当てた直後に CurrentPrincipal を確認すると、正しい値が表示されます。

于 2009-12-19T09:58:46.513 に答える