При настройке службы для федерации 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 теперь работает как положено. *