Partilhar via

Federação

  • Artigo

A federação permite a delegação da autoridade de autorização a outros membros de um interpriseio. Por exemplo, considere o seguinte problema comercial: 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 pedido de peças da Contoso. Uma solução de segurança para esse cenário é que a Contoso configure um mecanismo de confiança com a Fabrikam para delegar a decisão de autorização de acesso à Fabrikam. Este processo poderia funcionar da seguinte forma:

  • 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ão a autorização da Fabrikam e serão aceitáveis para a Contoso. Por exemplo, pode ser decidido que um certificado X.509 confiável com nome de assunto "CN=Fabrikam Inc Supplier STS" deve assinar um token SAML para que esse SAML seja aceito pelo Serviço Web Contoso. Além disso, pode ser decidido que a reivindicação de segurança no token SAML emitido deve ser 'https://schemas.contoso.com/claims/lookup' (para autorização de pesquisa de peças) ou 'https://schemas.contoso.com/claims/order' (para autorização de pedido de peças).
  • Quando um funcionário da Fabrikam usa o aplicativo interno de pedidos de peças, ele primeiro entra em contato com um serviço de token de segurança (STS) dentro da Fabrikam. Esse funcionário é autenticado usando o mecanismo de segurança interno da Fabrikam (por exemplo, nome de usuário/senha de domínio do Windows), sua autorização para encomendar peças é verificada e ele recebe um token SAML de curta duração contendo as declarações apropriadas e assinado pelo certificado X.509 decidido acima. Em seguida, o aplicativo de pedidos de peças entra em contato com o serviço da Contoso que apresenta o token SAML emitido para autenticar e executar a tarefa de pedido.

Aqui, o STS da Fabrikam atua como a "parte emissora" e o serviço de peças 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

A seguir estão os recursos de segurança suportados 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 função WsRequestSecurityToken. Como alternativa, pode-se usar uma biblioteca de provedor de token de segurança do lado do cliente, como CardSpace ou LiveID, e usar sua saída para criar localmente um token de segurança usando WsCreateXmlSecurityToken. De qualquer forma, uma vez que o cliente tenha o token de segurança, ele pode criar um canal para o serviço especificando WS_XML_TOKEN_MESSAGE_SECURITY_BINDING apresentar o token, juntamente com uma ligaçã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 ligação de segurança de transporte, como WS_SSL_TRANSPORT_SECURITY_BINDING para proteger o canal.
  • Lado STS: 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 descrição de segurança estrutura no momento da criação do ouvinte, assim como qualquer outro Serviço Web seguro. Em seguida, ele pode analisar cargas úteis de mensagens de solicitação de entrada para validar as solicitações de token e enviar de volta tokens emitidos como cargas úteis de mensagens de resposta. Atualmente, nenhum recurso é fornecido para ajudar nessas etapas de análise e emissão.

Observe que o lado do cliente pode manipular o token de segurança emitido genericamente como um token de segurança XML sem conhecer o tipo de token ou fazer o processamento específico do tipo de token. No entanto, o servidor tem que 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 as construções definidas 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 autentica-se no STS do LiveID usando um nome de usuário/senha do LiveID e obtém um token de segurança T1.
  • O cliente autentica no STS1 usando T1 e obtém um token de segurança T2.
  • O cliente autentica no STS2 usando T2 e obtém um token de segurança T3.
  • O cliente autentica 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 de tais funções funcionais STS incluem provedor de identidade, tomador de decisões de autorização, anonimizador e gerente de recursos.

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

Para que o cliente faça uma chamada deWsRequestSecurityToken bem-sucedida, ele precisa conhecer os parâmetros dessa chamada (como o tipo de token necessário e os tipos de declaração), a descrição de segurança os requisitos do canal de solicitação para o STS e o endereço de 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 de nível de aplicativo configurado pelo implantador de aplicativo local.
  • Descubra dinamicamente essas informações em tempo de execução 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 de 3 STS acima. O cliente primeiro fará um MEX dinâmico com S para obter informações sobre T3 (ou seja, o que pedir do STS2), bem como o endereço MEX dinâmico do STS2 (ou seja, onde encontrar o 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 dinâmicas do MEX ocorrem na ordem 4, 3, 2, 1 para construir a cadeia de federação e as etapas de solicitação e apresentação de token ocorrem na ordem 1, 2, 3, 4 para desenrolar a cadeia de federação.

Observação

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