Ler em inglês

Compartilhar via


Federação

A federação permite a delegação de autoridade de autorização para outros membros de uma interprise. Por exemplo, considere o seguinte problema de negócios: a empresa de fabricação de autopeças Contoso Ltd gostaria de permitir que funcionários autorizados de seu cliente Fabrikam Inc acessem com segurança o serviço Web de pedidos de peças da Contoso. Uma solução de segurança para esse cenário é a Contoso configurar um mecanismo de confiança com a Fabrikam para delegar a decisão de autorização de acesso à Fabrikam. Esse processo pode funcionar da seguinte maneira:

  • A Fabrikam, quando se torna parceira da Contoso, configura um contrato de confiança com a Contoso. O objetivo desta etapa é concordar com o tipo de token de segurança e o conteúdo que representará a autorização da Fabrikam e será aceitável para a Contoso. Por exemplo, pode ser decidido que um certificado X.509 confiável com o nome da entidade "CN=Fabrikam Inc Supplier STS" deve assinar um token SAML para que o SAML seja aceito pelo Serviço Web da Contoso. Além disso, pode ser decidido que a declaração de segurança no token SAML emitido deve ser 'https://schemas.contoso.com/claims/lookup' (para autorização de pesquisa de parte) ou 'https://schemas.contoso.com/claims/order' (para autorização de ordenação de parte).
  • Quando um funcionário da Fabrikam usa o aplicativo de ordenação de partes internas, ele entra em contato primeiro com um STS (serviço de token de segurança) dentro da Fabrikam. Esse funcionário é autenticado usando o mecanismo de segurança interno da Fabrikam (por exemplo, nome de usuário/senha do domínio do Windows), sua autorização para ordenar partes é verificada e ele recebe um token SAML de curta duração contendo as declarações apropriadas e assinado pelo certificado X.509 decidido acima. O aplicativo de ordenação de partes entra em contato com o serviço Contoso que apresenta o token SAML emitido para autenticar e executar a tarefa de ordenação.

Aqui, o STS da Fabrikam atua como a "parte emissora" e o serviço de partes da Contoso atua como a "terceira parte confiável". Diagrama mostrando uma parte emissora e uma terceira parte confiável em uma federação.

Recursos de federação

Veja a seguir os recursos de segurança com suporte para as partes ou funções envolvidas em um cenário de federação:

  • Lado do cliente: para obter o token de segurança do STS, pode-se usar a função WsRequestSecurityToken . Como alternativa, pode-se usar uma biblioteca de provedores de token de segurança do lado do cliente, como CardSpace ou LiveID, e, em seguida, usar sua saída para criar localmente um token de segurança usando WsCreateXmlSecurityToken. De qualquer forma, depois que o cliente tiver o token de segurança, ele poderá criar um canal para o serviço especificando WS_XML_TOKEN_MESSAGE_SECURITY_BINDING para apresentar o token, juntamente com uma associação de segurança de transporte, como WS_SSL_TRANSPORT_SECURITY_BINDING para proteger o canal.
  • Lado do servidor: em um cenário de federação com um serviço de token de segurança que emite tokens SAML, o servidor pode usar o WS_SAML_MESSAGE_SECURITY_BINDING, juntamente com uma associação de segurança de transporte, como WS_SSL_TRANSPORT_SECURITY_BINDING para proteger o canal.
  • StS-side: observe que o STS é um aplicativo de Serviço Web e pode especificar os requisitos de segurança para aqueles que solicitam um token de segurança dele usando uma estrutura de descrição de segurança no momento da criação do ouvinte, assim como qualquer outro serviço Web seguro faria. Em seguida, ele pode analisar os conteúdos de mensagens de solicitação de entrada para validar as solicitações de token e enviar tokens emitidos de volta como conteúdos de mensagens de resposta. Atualmente, nenhum recurso é fornecido para ajudar essas etapas de análise e emissão.

Observe que o lado do cliente pode lidar com o token de segurança emitido genericamente como um token de segurança XML sem saber o tipo de token ou fazer processamento específico do tipo de token. No entanto, o servidor precisa entender o tipo de token de segurança específico para entendê-lo e processá-lo. As etapas de solicitação e resposta do token de segurança usam os constructos definidos na especificação WS-Trust.

Cenários de federação mais complexos

Um cenário de federação pode envolver vários STSs que formam uma cadeia de federação. Considere o seguinte exemplo:

  • O cliente é autenticado no LiveID STS usando um nome de usuário/senha do LiveID e obtém um token de segurança T1.
  • O cliente é autenticado no STS1 usando T1 e obtém um token de segurança T2.
  • O cliente é autenticado no STS2 usando T2 e obtém um token de segurança T3.
  • O cliente é autenticado no serviço de destino S usando T3.

Aqui, o LiveID STS, STS1, STS2 e S formam a cadeia de federação. Os STSs em uma cadeia de federação podem executar várias funções para o cenário geral do aplicativo. Exemplos dessas funções funcionais sts incluem provedor de identidade, tomador de decisão de autorização, anonimizador e gerenciador de recursos.

Parâmetros de solicitação STS e troca de metadados

Para que o cliente faça uma chamada WsRequestSecurityToken bem-sucedida, ele precisa saber os parâmetros dessa chamada (como o tipo de token e os tipos de declaração necessários), os requisitos de descrição de segurança do canal de solicitação para o STS e o endereço do ponto de extremidade do STS. O aplicativo cliente pode usar qualquer uma das seguintes técnicas para determinar essas informações:

  • Codifique as informações no aplicativo como parte das decisões de tempo de design.
  • Leia essas informações de um arquivo de configuração no nível do aplicativo configurado pelo implantador de aplicativo local.
  • Descubra dinamicamente essas informações em runtime usando o recurso de importação de metadados com a estrutura WS_ISSUED_TOKEN_MESSAGE_SECURITY_BINDING_CONSTRAINT .

Para ilustrar o uso do MEX dinâmico com federação, considere o exemplo 3 STS acima. O cliente primeiro fará um MEX dinâmico com S para obter informações sobre t3 (ou seja, o que perguntar do STS2), bem como o endereço MEX dinâmico STS2 (ou seja, onde encontrar STS2). Em seguida, ele usará essas informações para fazer um MEX dinâmico com STS2 para descobrir informações sobre T2 e STS1 e assim por diante.

Assim, as etapas mex dinâmicas ocorrem na ordem 4, 3, 2, 1 para compilar a cadeia de federação e as etapas de solicitação de token e apresentação ocorrem na ordem 1, 2, 3, 4 para desenrolar a cadeia de federação.

Observação

Windows 7 e Windows Server 2008 R2: o WWSAPI dá suporte apenas a Ws-Trust e Ws-SecureConversation , conforme definido pelo LWSSP (Lightweight Web Services Security Profile). Para obter detalhes sobre a implementação da Microsoft, consulte a seção Sintaxe MESSAGE do LWSSP.