WIF ChannelActingAs заявки на доступ от WCF

Я хочу получить доступ к настраиваемым утверждениям, добавленным к текущему участнику на уровне пользовательского интерфейса, из службы 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, передавая токен начальной загрузки, я не получаю утверждения, которые были добавлены к принципалу на предыдущем шаге.

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 и передать его по каналу, или есть лучший способ подойти к этому в целом?


person paul_k    schedule 09.08.2012    source источник


Ответы (1)


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

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

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

person allu    schedule 10.08.2012