Поток.CurrentPrincipal службы ASP.Net WCF выбрасывается некоторым перехватчиком в среде объединения (WIF) - PullRequest
4 голосов
/ 19 декабря 2009

У меня есть служба WCF для каждого вызова, которая размещается в IIS (.svc). В конструкторе службы я установил 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 = "" и имя равно NULL в Thread.CurrentPrincipal.Identity ), тогда как все эти значения все еще правильно заполнено на HttpContext.Current.User . Это говорит мне о том, что что-то перехватывает вызов операции и неправильно меняет текущий участник на какой-то общий, пустой, не прошедший проверку подлинности участник утверждений.

Я проверил идентификатор потока в конструкторе, а также в операции, и он одинаков в обоих местах, и оценил Thread.CurrentPrincipal в ближайшем окне после назначения из HttpContext.Current. Пользователь показывает, что идентификация потока задается правильно в конструкторе, поэтому что-то определенно выполняется между конструктором и методом, и что-то меняет мой Thread.CurrentPrincipal .

Кто-нибудь знает, что делает это, и как я могу предотвратить или исправить это поведение?

Ответы [ 4 ]

6 голосов
/ 19 августа 2010

Я только что столкнулся с подобной проблемой. Я установил свой пользовательский принципал в конструкторе моей службы WCF. Когда я покинул конструктор и вошел в метод, который я вызвал, thread.currentprincipal был переопределен пустым. Я решил это, добавив следующее поведение:

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

Это сработало для меня.

3 голосов
/ 22 декабря 2009

При настройке службы для федерации WIF, вы звоните

FederatedServiceCredentials.ConfigureServiceHost(this);

Часть этого вызова заключается в настройке пользовательского ServiceAuthorizationManager типа IdentityModelServiceAuthorizationManager на хосте службы. Этот диспетчер авторизации вызывается между активацией (созданием) экземпляра и выполнением операции, и он перезаписывает 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();
}

И теперь, когда я вхожу в свою служебную операцию, у меня есть правильное значение IClaimsPrincipal на Thread.CurrentPrincipal , поэтому декларативное PrincipalPermission теперь работает как положено. *

1 голос
/ 29 марта 2010

настройки конфигурации для вызова FederatedServiceCredentials.ConfigureServiceHost (это );

как указано ниже в 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" />
0 голосов
/ 19 декабря 2009

Я предполагаю, что ничто не перехватывает вызов. Либо CurrentPrincipal сбрасывается к тому времени, когда вы его просматриваете, либо вы находитесь в другом потоке.

Проверьте CurrentPrincipal сразу после присвоения ему, и вы должны увидеть правильное значение.

...