Este artigo foi traduzido por máquina.
Fluxo de trabalho do Windows
Protegendo os Serviços de Fluxo de Trabalho do WF 4
Zulfiqar Ahmed
Windows Workflow Foundation (WF) fornece uma experiência de criação visual para escrever a lógica de software. Depois que a lógica de software é implementada como um fluxo de trabalho, ele é executado pelo que hospeda o fluxo de trabalho em um host de fluxo de trabalho. Um serviço de fluxo de trabalho é um tipo especial de serviço da Web implementado usando um fluxo de trabalho e é disponibilizado para o consumidor hospedando-lo em um WorkflowServiceHost. Neste artigo, falarei sobre as opções de segurança dos hosts diferentes de fluxo de trabalho com um determinado foco no WorkflowServiceHost e os serviços de fluxo de trabalho. Vou explicar alguns pontos de extensibilidade principais que podem ser usados para estender o limite de segurança de serviços de fluxo de trabalho para a camada de fluxo de trabalho. Também falarei sobre o projeto do pacote de segurança de fluxo de trabalho (WFSP) e como sua coleção de atividades pode ser usada para introduzir a segurança de ponta a ponta para soluções de fluxo de trabalho. WF 4, que é fornecido como parte do Microsoft.NET Framework 4, fornece uma API de hospedagem extensível e out-of-the-box de vem com três diferentes hosts com recursos variados.
WorkflowInvoker é a interface de host mais básico e com menos capacidade, fornecendo uma API simples para invocar os fluxos de trabalho. Um objeto WorkflowInvoker suporta apenas uma instância de fluxo de trabalho única, passada para ele via o construtor ou o método Invoke estático. Execução de fluxo de trabalho de todos os é garantida no mesmo thread de chamada, portanto, se o código de chamada está representando um contexto de segurança específico, todas as atividades serão executado nesse contexto representada. WorkflowInvoker não é um Host de fluxo de trabalho no sentido real;em vez disso, ele encapsula um host baseado em WorkflowApplication e usa um contexto de sincronização baseada em bomba para fornecer uma API fácil de usar com uma semântica consistente de execução. Por exemplo, exceções, transações e assim por diante perfeitamente fluam através do limite de invocação. Esse comportamento simplifica a segurança, pois o contexto de segurança do chamador está disponível durante a execução do fluxo de trabalho e atividades podem ser usada em vários cenários de segurança. Por exemplo, autorização de permissão Principal e a delegação Kerberos funcionam perfeitamente com WorkflowInvoker.
WorkflowApplication esse é um host com um pouco mais de capacidade, mas ainda oferece suporte a apenas uma única instância. Este host executa o fluxo de trabalho usando os threads de e/S do CLR ThreadPool. O contexto de segurança de um segmento de chamada não é copiado para o segmento de fluxo de trabalho, mesmo que o cliente de fluxo de trabalho está representando, o segmento do WF — que está executando as atividades — não ser representando. O contexto de segurança do chamador pode ser usado para o segmento WF usando um contexto personalizado de sincronização que deseja encaminhar a chamada no mesmo entrada Async thread, semelhante ao contexto de sincronização usado pelo WorkflowInvoker:
public class MySyncContext : SynchronizationContext
{
public override void Post(SendOrPostCallback d, object state)
{
d(state);
}
}
WorkflowServiceHost esse é o host mais abrangente, fornecendo um ambiente de hospedagem adequado para várias instâncias de fluxo de trabalho. Os serviços de fluxo de trabalho são um tipo especial de serviços da Web cuja implementação é baseada em fluxos de trabalho. WorkflowServiceHost deriva da classe ServiceHostBase Windows Communication Foundation (WCF) padrão e todos os conceitos de segurança do WCF se aplicam a WorkflowServiceHost também. Atividades de mensagens são o modelo de interação principal suportado pelo WorkflowServiceHost, juntamente com o WorkflowHostingEndpoint, que permite o uso do WorkflowServiceHost sem usar as atividades de messaging. Neste artigo, vou principalmente enfocar o aspecto da segurança das atividades, serviços de fluxo de trabalho e WorkflowServiceHost de mensagem. Para obter uma visão geral da tecnologia de serviços de fluxo de trabalho, confira artigo de Leon Welicki, "Visual Design de fluxos de trabalho com o WCF e WF 4," na edição de maio de 2010 da msdn Magazine ( msdn.microsoft.com/magazine/ff646977 ).
Segurança de fios de serviços de fluxo de trabalho
Como o fluxo de trabalho são serviços padrão do WCF, aspectos de segurança de conexão são configurados através dos mecanismos de ligação padrão do WCF. Um serviço de fluxo de trabalho pode ser exposto usando um ou mais pontos de extremidade usando uma ligação específica, de acordo com as necessidades de segurança do serviço. Um pipeline de despacho do WCF será executado somente se a mensagem de entrada satisfizer os requisitos de segurança do ponto de extremidade de destino. Lógica de fluxo de trabalho é executado no final de um pipeline de despacho, para que todos os pontos de extensibilidade WCF comuns são aplicáveis aos serviços de fluxo de trabalho também. Por exemplo, o ponto de extensibilidade padrão do ServiceAuthorizationManager pode ser usado para aplicar autorização para serviços de fluxo de trabalho também. Estruturas como o Windows identidade Foundation (WIF) integram com o WCF no nível do dispatcher e transparente, que podem ser usadas com os serviços de fluxo de trabalho também. Existem algumas diferenças de segmentação, relacionadas a alguns pontos assíncronos entre as camadas WCF e WF, tornam determinados cenários de TLS de armazenamento Local de segmento um pouco mais desafiador nos serviços de fluxo de trabalho. Por exemplo, WIF expõe as informações de identidade de entrada usando o thread. CurrentPrincipal e torna-se de definir isso corretamente para os serviços baseados em código. No entanto, a lógica do fluxo de trabalho pode acabar em execução em um thread diferente do thread original do WCF. Se isso acontecer, todos os dados relacionados a TLS — incluindo o Thread.CurrentPrincipal—won't ser válido, portanto, é recomendável não dependem de TLS em seus fluxos de trabalho. Falarei sobre algumas soluções possíveis para isso em uma seção posterior.
4 O WF também fornece uma atividade enviar para chamar outros serviços Web a partir de um fluxo de trabalho. A atividade enviar pode ser configurada com uma ligação que seria usada ao chamar outros serviços de dentro do fluxo de trabalho. Internamente, a atividade enviar usa a API de ChannelFactory/canal WCF padrão para envio de mensagens e a ligação configurada é usada para criar essa fábrica de canais internos. Envie a atividade também tem uma camada de cache embutida nele que usou para o cache de ChannelFactory/canal. Por padrão, essa camada de cache é usada apenas se as informações de ponto de extremidade são especificadas usando diretamente as propriedades da atividade enviar e uma ligação de ações é escolhida, conforme mostrado na a Figura 1 .
Figura 1 envie as propriedades de atividade
Assim que informações de ponto de extremidade são carregadas a partir do arquivo de configuração usando a propriedade EndpointConfigurationName, a segurança está desativado e cada execução de atividade enviar cria um novo ChannelFactory. Ligações seguras, como a wsHttpBinding e wsFederationHttpBinding não muito trabalho na fábrica de canal abrindo o Palco e recriar uma fábrica de canais para cada mensagem pode ser bastante caro. Por exemplo, o padrão é otimizado para desempenho e segurança e consegue isso estabelecendo uma sessão de conversação segura que tem um custo antecipado de WSHttpBinding, mas mensagens subseqüentes podem ser protegidas com um custo muito menor. Sem cache ChannelFactory, esse comportamento ideal de WSHttpBinding fica uma sobrecarga porque para todas as mensagens de negócios, quatro componentes adicionais são enviadas para negociar as credenciais de serviço e, em seguida, estabelecer uma sessão de conversação segura, como mostrado na a Figura 2 .
Figura 2 Infrastructure mensagens enviadas para negociar as credenciais de serviço
| https://schemas.xmlsoap.org/ws/2005/02/trust/RST/Issue |
| https://schemas.xmlsoap.org/ws/2005/02/trust/RSTR/Issue |
| https://schemas.xmlsoap.org/ws/2005/02/trust/RST/SCT |
| http://tempuri.org/IPingService/ping |
| https://schemas.xmlsoap.org/ws/2005/02/trust/RST/SCT/Cancel |
No WF 4, qualquer configuração de ligação carregada do arquivo de configuração (até mesmo as ligações padrão) é tratada como "não seguro para armazenar em cache" pela atividade enviar e ChannelFactory armazenamento em cache está desabilitado. Esse comportamento padrão pode ser substituído, forçando o cache de canal seguro, que será reutilizar o ChannelFactory para enviar mensagens para o mesmo ponto de extremidade. SendMessageChannelCache o comportamento de serviço permite o cache não seguros e também permite a configuração para as configurações de cache de vários canais e ChannelFactory, conforme mostrado aqui:
<serviceBehaviors>
<behavior>
<sendMessageChannelCache allowUnsafeCaching="true">
<channelSettings idleTimeout="1:0:0" maxItemsInCache="60"/>
<factorySettings idleTimeout="1:0:0" maxItemsInCache="60"/>
</sendMessageChannelCache>
</behavior>
</serviceBehaviors>
Onde está meu OperationContext?
Nos serviços tradicionais baseadas em código, informações de segurança para a chamada de entrada estão disponíveis via o OperationContext. O tempo de execução do WCF dispatcher certifica-se de definir o OperationContext no thread antes de chamar o método de serviço, por isso dentro do método de serviço, informações de segurança são acessíveis usando o OperationContext.
Serviços de fluxo de trabalho adicionam complexidade adicional porque há um monte de pontos assíncronos entre dispatcher WCF e execução de fluxo de trabalho. Qualquer um desses points async pode alternar o thread, no qual fluxo de trabalho caso lógica (atividades) seria executado em um thread diferente do thread do WCF e OperationContext seria disponível usando a abordagem OperationContext. No WF 4, o acesso de thread agnóstica para OperationContext está ativado usando um mecanismo de retorno de chamada com base em IReceiveMessageCallback e ISendMessageCallback. IReceiveMessageCallbacks são usados no lado do servidor, enquanto ISendMessageCallbacks dar acesso a OperationContext no lado do cliente. No lado do servidor, os IReceiveMessageCallbacks são invocados logo depois que uma mensagem é recebida por uma atividade receber. Para anexar esses retornos de chamada para enviar e receber as atividades, devem estar disponíveis como propriedades de execução quando executa de envio/recebimento. Uma abordagem comum para adicionar propriedades de execução para uma atividade é criar uma atividade de escopo pai e definir as propriedades de execution como parte da execução da atividade pai, conforme mostrado na a Figura 3 .
Figura 3 uma atividade escopo simples para adicionar propriedades de execução
[ContentProperty("Body")]
public sealed class OperationContextScope : NativeActivity
{
public Activity Body { get; set; }
protected override void Execute(NativeActivityContext context)
{
if (this.Body != null)
{
// Adding an execution property to handle OperationContext
context.Properties.Add(OperationContextScopeProperty.Name,
new OperationContextScopeProperty());
context.ScheduleActivity(this.Body);
}
}
}
No trecho de código em a Figura 3 , quando a atividade OperationContextScope é executado, ele simplesmente adiciona uma propriedade de execução para o contexto para que todas as atividades filho podem ver essa propriedade de execução. Atividades Send e Receive procuram as propriedades de retorno de chamada mencionado anteriormente, e se uma dessas propriedades for encontrada, ele é chamado no estágio correto da mensagem de processamento, permitindo acesso OperationContext. Neste exemplo, qualquer atividade de recebimento que farão parte do mesmo escopo vê o OperationContextScopeProperty e executa o retorno de chamada passando o valor OperationContext (consulte a Figura 4 ).
Figura 4 ReceiveMessageCallback implementado como uma propriedade de execução
[DataContract]
class OperationContextScopeProperty : IReceiveMessageCallback, IExecutionProperty
{
private OperationContext current;
private OperationContext orignal;
public static readonly string Name =
typeof(OperationContextScopeProperty).FullName;
public void OnReceiveMessage(OperationContext operationContext,
ExecutionProperties activityExecutionProperties)
{
current = operationContext;
operationContext.OperationCompleted
+= delegate(object sender, EventArgs e)
{
current = null;
};
}
public void CleanupWorkflowThread()
{
OperationContext.Current = orignal;
}
public void SetupWorkflowThread()
{
orignal = OperationContext.Current;
OperationContext.Current = current;
}
}
OperationContextScopeProperty simplesmente captura e armazena o OperationContext atualmente ativo e define-lo posteriormente no thread correto do WF usando o mecanismo do WF TLS. A interface IExecutionProperty tem métodos de instalação/CleanUpWorkflowThread, que são chamados de antes e depois da execução de cada WF (atividade) do item de trabalho e dar a capacidade de definir várias propriedades relacionadas a TLS thread selecionada do WF, OperationContext sendo um exemplo nesse caso.
OperationContextScope é um exemplo de uma atividade personalizada que aproveita a extensibilidade do WF 4 para permitir o acesso independente de thread OperationContext WCF para todas as atividades filho dentro do escopo.
Serviços de fluxo de trabalho e WIF
WIF fornece um modelo de API e o objeto rich para habilitar a declaração de serviços WCF e ASP.NET applications. WIF integra-se com o WCF no nível do host, a maioria dos recursos WIF funciona bem com os serviços de fluxo de trabalho. Verifique a minha postagem de blog bit.ly/a6pWgA para obter detalhes adicionais sobre como integrar WIF com serviços de fluxo de trabalho. A integração de out-of-box funciona bem para cenários básicos, embora cenários avançados adicionais podem ser ativados usando as atividades de WFSP.
Apresentando o CTP WFSP 1
WFSP CTP (Community Technology Preview) 1 fornece um conjunto de atividades e comportamento associado do WCF para habilitar cenários de segurança de chave 4 do WF. WFSP utiliza o modelo de extensibilidade de ISend/IReceiveMessageCallback para implementar a muitos de seus recursos. CTP 1 de WFSP foi lançado no CodePlex em de 2010 de julho e pode ser baixado em wf.codeplex.com/releases/view/48114 .
Atividades WFSP, mostradas na a Figura 5 , misturam bem com o restante do WF e fornecem poderosas construções para introduzir a segurança integrada em soluções de fluxo de trabalho.
Figura 5 atividades de pacote de segurança de fluxo de trabalho
Autorização no fluxo de trabalho
Nos serviços de fluxo de trabalho, você pode usar a extensibilidade do WCF ServiceAuthorizationManager padrão para implantar a autorização e esse recurso funciona exatamente como em serviços baseados em código. No entanto, em alguns cenários (por exemplo, onde os dados de autorização são parte do fluxo de trabalho), você gostaria de adiar a decisão de autorização até a execução do fluxo de trabalho real. PrincipalPermissionScope é uma atividade de servidor que oferece o recurso de autorização do CLR PrincipalPermission aos fluxos de trabalho. Nenhuma atividade filho colocada dentro do escopo serão executados somente se a demanda de permissão foi concluída com êxito. Esta atividade procura as informações de identidade o contexto de segurança do WCF entrada acessada de OperationContext. PrincipalPermissionScope é implementado usando o mesmo mecanismo de IReceiveMessageCallback mencionado anteriormente neste artigo.
A demanda real PrincipalPermission é imposta em relação a um objeto IPrincipal com base no valor de ServiceAuthorizationBehavior.PrincipalPermissionMode. Este recurso de extensibilidade permite PrincipalPermissionScope trabalhar com um aplicativo ASP.NET provedor de função, bem como uma implementação personalizada de IPrincipal produzido por um IAuthorizationPolicy personalizado. Fazer check-out msdn.microsoft.com/library/aa702542 para obter detalhes sobre como configurar aplicativos ASP.NET o provedor de função com um serviço WCF.
Atividades de mensagens e mensagens autenticadas
Envie a atividade fornece a principal forma de consumir serviços Web a partir de fluxos de trabalho. Na maioria dos cenários do mundo real, esses serviços back-end são protegidos em exigem a autenticação antes de fazer qualquer trabalho. Em serviços padrão baseada em código, informações de credencial são especificadas usando a propriedade ClientCredential exposta na ChannelFactory e uma <T> de ClientBaseclasse de proxy derivada. Usar esta propriedade, um cliente pode especificar a credencial que deseje usar antes de chamar o serviço. Infelizmente, envie a atividade, que envolve o ChannelFactory, não expõe ClientCredential no WF 4, portanto, algumas situações que exigem a especificação explícita de credencial não são possíveis com out-of-box enviar atividade. Observe que atividade enviar selecione a configuração de comportamento de ponto de extremidade no arquivo de configuração, para que você possa criar um comportamento de ponto de extremidade personalizado para especificar essas credenciais.
Um exemplo típico que requer credenciais explícitas está chamando um serviço configurado para exigir uma nome de usuário/senha. Como a propriedade ClientCredential não é exposta na atividade enviar, não há nenhuma maneira de especificar uma nome de usuário/senha. Vamos ver como a atividade de GetUserNameSecurityToken de WFSP oferece uma solução para esse e outros cenários relacionados.
Em a Figura 6 , atividade de Ping é gerada pelo Assistente "Add Service Reference" e é configurada para chamar um serviço que está protegido para exigir autenticação de nome de usuário, como mostrado na seguinte configuração de ligação:
<wsHttpBinding>
<binding name="singleShotUserName">
<security mode="Message">
<message clientCredentialType="UserName" establishSecurityContext
="false" />
</security>
</binding>
</wsHttpBinding>
Figura 6 autenticados usando um Token de nome de usuário de mensagens
O fluxo de trabalho anterior, o GetUserNameSecurityToken cria uma UserNameSecurityToken baseada a nome de usuário/senha fornecida e inscreve-lo com o ambiente SecurityTokenHandle fornecida pela atividade TokenFlowScope. "Pacote de segurança de fluxo de trabalho" se aplica a segurança no nível do SecurityToken em oposição ao /ClientBase de ChannelFactory <T>abordagem da aplicação de segurança no nível de credencial. No WCF padrão, as credenciais são usadas para criar tokens de segurança, mas WFSP usa tokens de segurança diretamente e toca a camada de segurança do WCF no nível de token em vez do nível de credenciais.
TokenFlowScope é a atividade de chave que permite que outros cenários interessantes e mensagens autenticadas. Nesta atividade, juntamente com o comportamento de ponto de extremidade de WorkflowClientCredentials, flui os tokens alistados da camada de fluxo de trabalho para a camada de segurança do WCF, onde estiver conectados com a mensagem de saída de acordo com os requisitos de ligação do ponto de extremidade. TokenFlowScope requer um comportamento personalizado de ClientCredential (WorkflowClientCredentials) a ser configurado, conforme mostrado no seguinte trecho de configuração:
<behavior>
<!--This custom clientCredentials enables the credential flow from
workflow data model into WCF security layer.
-->
<clientCredentials
type="Microsoft.Security.Activities.WorkflowClientCredentials,
Microsoft.Security.Activities, Version=1.0.0.0, Culture=neutral,
PublicKeyToken=31bf3856ad364e35">
</clientCredentials>
</behavior>
WFSP segue esse modelo exato quando chamar um serviço que requer um token de um serviço STS (Security Token), conforme mostrado na a Figura 7 .
Figura 7 de Token SAML um controle refinado de aquisição e uso
Em a Figura 7 , GetSamlSecurityToken, vai para um emissor e adquire um token SAML que está inscrito, em seguida, com o identificador de ambiente fornecido pela atividade TokenFlowScope. Esta inscrição disponibiliza esse token para qualquer atividade enviar vivendo no mesmo escopo e exigindo um SAML token. O modelo é extensível e GetSamlSecurityToken pode-se usar um token já alistado ao obter um token SAML, por exemplo, se o STS requer um token de nome de usuário para retornar um token SAML e se já houver um token de nome de usuário válido inscrito no escopo. GetSamlSecurityToken, quando configurado com o comportamento de WorkflowClientCredentials, usaria esse token ao solicitar um token SAML.
Out-of-box WFSP só oferece suporte a tipos de token UserName e SAML;No entanto, outros tipos de token podem ser ativados por herança da classe GetSecurityToken, conforme mostrado no trecho de código em a Figura 8 , que implementa uma atividade para criar um símbolo de baseados em 509 X.
Figura 8 WFSP extensibilidade: tipos de Token adicional a implementação
[Designer(typeof(GetX509SecurityTokenDesigner))]
public class GetX509SecurityToken : GetSecurityToken
{
public GetX509SecurityToken()
{
FindType = X509FindType.FindBySubjectName;
StoreLocation = StoreLocation.CurrentUser;
StoreName = StoreName.My;
}
public InArgument<X509Certificate2> Certificate { get; set; }
public X509FindType FindType { get; set; }
public StoreLocation StoreLocation { get; set; }
public InArgument<string> FindValue { get; set; }
public StoreName StoreName { get; set; }
protected override void Execute(NativeActivityContext context)
{
X509Certificate2 targetCert = null;
if (this.Certificate != null)
targetCert = this.Certificate.Get(context);
if (targetCert == null)
{
var store = new X509Store(StoreName, StoreLocation);
try
{
store.Open(OpenFlags.ReadOnly);
var col = store.Certificates.Find(FindType, FindValue.Get(context), false);
if (col.Count > 0)
targetCert = col[0];//Use first certificate mathing the search criteria
}
finally
{
if (store != null)
store.Close();
}
}
if (targetCert == null)
throw new InvalidOperationException(
"No certificate found using the specified find criteria.");
// Enlist the token as a flow token
base.EnlistSecurityToken(context, new X509SecurityToken(targetCert));
}
}
GetX509SecurityToken cria um token de X509Security com base em um certificado e inscreve-lo com o SecurityTokenHandle como um símbolo de fluxo pode ser usado para chamar um serviço que requer um certificado para autenticação. Figura 9 mostra GetX509SecurityToken em uso com um designer de atividade personalizada.
Figura 9 TokenFlowScope com uma atividade de GetToken personalizada
Delegação baseada em declarações
A delegação baseada em declarações é outro recurso útil ativado por WFSP. A delegação baseada em declarações geralmente é mais desejável para serviços de fluxo de trabalho, esses serviços principalmente implementam um processo de negócios/orquestração chamar vários serviços de back-end. Além disso, o acesso à identidade do chamador nesses serviços back-end geralmente é necessário para habilitar as decisões de autorização apurada. WFSP aproveita a funcionalidade de ActAs do WS-Trust 1. 4 para permitir que qualquer tipo de token ser usado como um símbolo de ActAs. Por padrão, todas as atividades de GetToken criar um token e inscrever-se como um símbolo de fluxo — no entanto, todas essas atividades também têm um sinalizador conhecido como IsActAsToken, conforme mostrado na a Figura 10 .
Figura 10 criar um símbolo de ActAs
Quando esse sinalizador estiver marcado, a lógica de criação de token permanece o mesmo, mas o T1 token criado está inscrito como um símbolo de ActAs em vez de um token de fluxo. Pode haver apenas um token de ActAs por escopo, e é consumido pela atividade de GetSamlSecurityToken ao solicitar um token SAML. Quando GetSamlSecurityToken é executado, o token ActAs ativo é pegou e é enviado como parte de uma solicitação de emissão de token gerada pela atividade GetSamlSecurityToken. T2 token retornado conteria as declarações do token de autenticação, bem como o símbolo de ActAs. Finalmente, qualquer atividade de envio em execução dentro desse escopo pode usar esse token T2 ao chamar um serviço back-end que veria ambas as identidades no seu contexto de segurança.
Atividade GetBootstrapToken é usada em cenários de camada intermediária para ativar a delegação baseada em declarações de ponta a ponta. Ao contrário de atividades GetToken, essa atividade simplesmente lê o token de entrada e inscreve-lo como um símbolo de ActAs em vez de criar um novo token e, em seguida, inscrevendo. Atividade GetBootstrapToken permite que um serviço de fluxo de trabalho para usar a identidade do chamador de entrada, com sua própria identidade, ao chamar os serviços de back-end, como mostrado na a Figura 11 .
Figura 11 Completa de fluxo de delegação baseada em declarações
Na etapa 3 de a Figura 11 , serviço de fluxo de trabalho usa atividades WFSP para ler o token de entrada de bootstrap, adquire um novo token que atua como a identidade do token bootstrap e passa, então, as duas identidades para um servidor back-end. Figura 12 mostra o fluxo de trabalho que é usado por este serviço de fluxo de trabalho.
Figura 12 fluxo de trabalho de delegação baseada em declarações
O fluxo de trabalho mostrado na Figura 12, atividade GetBootstrap é colocada dentro de um OperationContextScope para garantir o acesso do segmento agnóstica OperationContext quando esta atividade é executada. GetSamlSecurityToken usa o símbolo de ActAs produzido na etapa anterior pela atividade GetBootstrapToken e, finalmente, a atividade de eco chama o serviço de back-end com um token SAML final produzido pela atividade GetSamlSecurityToken.
Representação/delegação do Windows
ImpersonatingReceiveScope é outra atividade do servidor que traz a representação do Windows e a delegação para o mundo de fluxo de trabalho. Quando essa atividade é executado, ele procura uma WindowsIdentity dentro do contexto de segurança de entrada. Se a mensagem de entrada produz uma WindowsIdentity, todas as atividades filho que fazem parte do corpo serão executada dentro desse escopo representado. ImpersonatingReceiveScope usa o mecanismo de fluxo de trabalho TLS, mencionado anteriormente neste artigo, para representar a identidade no thread do WF antes de executar um item de trabalho. Representação é revertida quando o item de trabalho do WF conclui a execução.
Falha ao localizar uma WindowsIdentity válida no contexto de segurança de entrada, ImpersonatingReceiveScope procura uma declaração de UPN — em uma identidade WIF (thread. CurrentPrincipal) ou na ClaimsSet do WCF tradicionais — e o usa para criar um WindowsToken usando os recursos do S4U do Kerberos. Para transformar uma declaração de UPN para um token do Windows, ImpersonatingReceiveScope depende "Declarações para Windows Token Service", que faz parte do tempo de execução WIF. Este serviço deve ser instalado e em execução para a transformação de declarações ao token seja bem sucedido.
Figura 13 mostra um uso típico da atividade ImpersonatingReceiveScope.
Figura 13 ImpersonatingRecieveScope em ação
Segurança de ponta a ponta
De fora, serviços de fluxo de trabalho são serviços WCF padrão e, como tal, a maioria das opções de segurança do WCF é aplicável aos serviços de fluxo de trabalho também. O WF 4 apresentou alguns pontos de extensibilidade principais que podem ser usados para ampliar ainda mais o limite de segurança de serviços de fluxo de trabalho para a camada de fluxo de trabalho. WFSP fornece um conjunto de atividades que use esses pontos de extensibilidade para introduzir a segurança de ponta a ponta para 4 do WF.
Zulfiqar Ahmedé consultor sênior sobre o Premier Support para equipe de desenvolvedores e é o autor original do projeto de fluxo de trabalho Security Pack. Ele mantém um blog em zamd.net , onde ele aborda tópicos que vão desde o Windows Communication Foundation, Windows Workflow Foundation e segurança baseada em declarações para a Microsoft geral.NET Framework coisas.
Graças ao especialista técnico seguinte pela revisão deste artigo: Dave Cliffe