Thread.CurrentPrincipal de servicio de ASP.Net WCF está siendo tirado por algún interceptor en un entorno federado (WIF)

Question

Tengo un servicio de WCF por llamada que se está alojada en IIS (.svc). En el constructor del servicio, me puse Thread.CurrentPrincipal = HttpContext.Current.User como por este artículo . En este caso HttpContext.Current.User es de tipo Microsoft.IdentityModel.Claims.ClaimsPrincipal y tiene las reclamaciones que fueron enviadas de vuelta de mis STS personalizada pasivos.

Sin embargo, tan pronto como me paso en mi explotación del servicio y examino Thread.CurrentPrincipal , mientras que este objeto es todavía de tipo Microsoft.IdentityModel.Claims.ClaimsIdentity , la objeto en sí mismo ya no es el mismo que HttpContext.Current.User ( IsAuthenticated = false, AuthenticationType = "" y nombre es nulo en Thread.CurrentPrincipal.Identity ), mientras que estos Los valores están siendo llenados correctamente en HttpContext.Current.User . Esto me dice que algo está interceptando la llamada a la operación y cambiar incorrectamente el director actual de algunos genéricos, vacío, reclamaciones director no autenticado.

He comprobado el ID del hilo en el constructor, así como en la operación y es el mismo en ambos lugares, y evaluando Thread.CurrentPrincipal en la ventana inmediata después de la asignación de HttpContext.Current .User muestra que la identidad de hebra se está configurado correctamente en el constructor, por lo que algo es, sin duda ejecutando entre el constructor y el método, y que algo está cambiando mi Thread.CurrentPrincipal .

¿Alguien tiene alguna idea de lo que está haciendo esto, y cómo puedo ir sobre la prevención / la fijación de este comportamiento?

Answer 1

Al configurar un servicio para la federación WIF, se llama

FederatedServiceCredentials.ConfigureServiceHost(this);

Parte de lo que hace esta llamada es la creación de una costumbre ServiceAuthorizationManager de tipo IdentityModelServiceAuthorizationManager en el host de servicio. Este gestor de autorización parece ser llamado en el medio de activación (construcción) de la instancia y la ejecución de la operación, y se sobrescribe Thread.CurrentPrincipal con una instancia de IClaimsPrincipal , pero no parece darse cuenta de que se está ejecutando en el modo de compatibilidad de ASP.NET, por lo que no se tire al director de HttpContext.Current.User .

yo era capaz de evitar este comportamiento mediante la derivación de IdentityModelServiceAuthorizationManager y anulando el CheckAccess método de la siguiente manera:

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;
    }
}

Esto entonces se aplica al host de servicio de la siguiente manera:

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

Y ahora cuando entro en mi operación de servicio, tengo la correcta IClaimsPrincipal en Thread.CurrentPrincipal , de manera declarativa PrincipalPermission ahora funciona como se esperaba .

Answer 2

Me acabo de encontrar con un problema similar. Me puse mi director de costumbre en el constructor de mi servicio WCF. Cuando dejé el constructor, y entré en el método que se llama, el Thread.CurrentPrincipal fue anulado por una vacía. He resuelto esto añadiendo el siguiente comportamiento:

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

Esto funcionó bien para mí.

Answer 3

Configuración de confguración de llamada FederatedServiceCredentials.ConfigureServiceHost (esto );

es la siguiente en system.serviceModel añadir siguiente

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

en el interior de añadir folowing línea

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

Answer 4

Mi conjetura es que nada está interceptando la llamada. O bien el CurrentPrincipal se restablece en el momento en que está examinándola o estás en un hilo diferente.

Compruebe el CurrentPrincipal inmediatamente después de asignar a la misma y debería ver el valor correcto.