Требования к доступу WIF ChannelActingAs от WCF

Question

Я хочу получить доступ к пользовательским претензиям, добавленным к текущему основному пользователю в слое пользовательского интерфейса, из службы WCF. У меня есть веб-приложение, которое добавляет претензии к CurrentPrincipal, как только пользователь был аутентифицирован STS. Это прекрасно работает.

protected void WSFederationAuthenticationModule_SecurityTokenValidated(object sender, SecurityTokenValidatedEventArgs args) 
    { 
     var customPrincipal = new ClaimsPrincipal(args.ClaimsPrincipal); 
     var service = ServiceLocator.Current.GetInstance<IServices>(); 

     Thread.CurrentPrincipal = customPrincipal; 
     var result = service.GetPemissions(); 

     foreach (var claim in result.Claims) 
      customPrincipal.Identities.First().Claims.Add(new Claim(claim.ClaimType, claim.Value));      

     Thread.CurrentPrincipal = customPrincipal; 
     args.ClaimsPrincipal = customPrincipal; 
    } 

В какой-то момент я хотел бы сделать запрос в службу WCF и передать претензии в службу. Если я использую передачу CreateChannelActingAS в токене bootstrap, я не получаю заявки, которые были добавлены в основную часть с предыдущего шага.

var claimsPrincipal = Thread.CurrentPrincipal as IClaimsPrincipal; 
var securityToken = claimsPrincipal.Identities.First().BootstrapToken; 
using (var channel = channelFactory.Value.CreateChannelActingAs(securityToken) as IClientChannel) 
{ 
try 
    { 
     invocation.ReturnValue = invocation.Method.Invoke(channel, invocation.Arguments); 
    { ... 

Есть ли способ построить ClaimsPrincipal в WCF службы и имеют дополнительные претензии попадались, которые были добавлены в слое пользовательского интерфейса? Могу ли я создать новый securityToken и передать это через канал или есть лучший способ приблизиться к этому в целом?

Answer 1

Bootstraptoken буквально является токеном, из которого первоначально был создан Идентификатор WIF, и поэтому он не будет содержать никаких претензий, добавленных или преобразованных после первоначального создания. Способ работы WIF (с безопасными токенами) означает, что вызывающие клиенты никогда не смогут каким-либо образом манипулировать содержимым токена (или, по крайней мере, получатель не сможет проверить такие вредоносные токены).

В зависимости от выбранной архитектуры IDM существуют некоторые варианты продолжения. Самый простой вариант - сделать еще один вызов STS и указать требуемые дополнительные претензии в запросе RequestSecurityToken. Тем не менее, при рассмотрении STS можно либо принять, либо отклонить входящие требования, и существует множество вариантов обработки этого кода в пользовательском коде STS. Если нет контроля над STS (и никакой промежуточный ретранслятор не может быть настроен), трудным путем может быть использование дополнительной безопасности WCF, такой как поддержка токенов. Они требуют ручной настройки и операций, если они должны быть делегированы далее по дороге WCF.

Замечание о предупреждении, хотя модель управления идентификацией является, по существу, совокупностью отношений доверия и позволяя клиенту STS указывать на весь сайт (или где-либо когда токен распространяется/федерируется/и т. Д.) Действительные требования довольно теневые дизайн. В конце концов, поскольку претензии теперь поступают от вызывающих WCF, можно просто просто передать их, поскольку параметры в методе WCF вызывают anyways с точно таким же уровнем безопасности. Единственное преимущество от добавления их в токены идентификации WIF (правильно) будет заключаться в том, что они будут автоматически делегироваться/совместно использоваться в ситуациях ActAs/OnBehalfOf.