Cenário de delegação, federação e autenticação de exemplo no SharePoint
Este artigo apresenta os cenários de exemplo para delegação de identidade e a federação de identidade.
Exemplo de cenários
As empresas a empresa fictícias seguir e seus negócios indicado necessidades são usados nos cenários de exemplo que são descritos neste artigo:
Híbrida da Contoso é uma empresa de suprimentos de mecanismo de automóveis internacional especializada na fabricação mecanismos de híbrido elétrica e baseadas na célula de combustível fabricantes de carro dentro e fora dos Estados Unidos. Em um esforço estratégico para cumprir as partes ordenação demandas de seus clientes, o departamento de TI da Contoso é designado desenvolvendo e implantando um parts seguras de acesso à Internet ordenação aplicativo por meio do seu nome de host, Contoso.com. Esse aplicativo também deve fornecer vários níveis de acesso para vários usuários internos (funcionários da Contoso) e externo (funcionários do fabricante de carro). Para minimizar os custos associados à manutenção das partes ordenação aplicativo, IT também deve evitar a necessidade de aplicativo a usar e manter um armazenamento de conta adicionais para usuários internos e externos acessar o aplicativo.
Fabrikam Motors é um fabricante sueco de carros compact fuel-efficient e carros pequenos conhecido em todo o mundo para o seu ponto de preço baixo nos de automóveis híbrida. Embora vendas tem acelerado consistentemente ano após ano para Fabrikam, houve um aumento perceptível nas taxas de falha de mecanismo híbrida dentro de seu primeiro ano, em carros vendidos aos clientes. Para Fabrikam Motors manter seu padrão para altos níveis de serviço, ele deve implementar uma maneira mais eficiente de partes de mecanismo de híbrido para ser solicitados através de híbrida da Contoso.
Estes são os conceitos relacionados:
Federação de identidade. Explica o estabelecimento de federação entre híbrida da Contoso e Fabrikam Motors de modo que os usuários de Fabrikam obter uma experiência de single sign-on ao acessar recursos híbridos Contoso;.
Delegação de identidade. Explica a capacidade de acessar os recursos de um serviço web híbrida da Contoso que requer um token de ActAs; ou seja, o serviço requer a identidade do chamador imediato (geralmente, a identidade do serviço) e o usuário original que iniciou a solicitação (geralmente, a identidade do usuário interativa).
Delegação de identidade
Este cenário descreve um aplicativo que precisa acessar recursos de back-end que exigem a cadeia de delegação de identidade para executar verificações de controle de acesso. Uma cadeia de delegação de identidade simples consiste nas informações sobre o chamador inicial e a identidade do chamador imediato.
Com o modelo de delegação de Kerberos na plataforma Windows hoje, os recursos de back-end têm acesso apenas a identidade do chamador imediato e não do chamador inicial. Este modelo geralmente é conhecido como o modelo subsistema confiável. O WIF (Windows Identity Foundation) mantém a identidade do chamador inicial e do chamador imediato na cadeia de delegação usando a propriedade Delegado( ).
A Figura 1 mostra um cenário de delegação de identidade típico em que um funcionário da Fabrikam acessa recursos expostos em um aplicativo de Contoso.com. Figura 1. Claims federation authentication
Os usuários de empresa fictícios participando neste cenário são:
Frank: Um funcionário da Fabrikam que deseje acessar os recursos da Contoso.
Daniel: Contoso desenvolvedor de aplicativo de quem implementa as alterações necessárias no aplicativo.
ADAM: O Contoso administrador de TI.
Os componentes envolvidos neste cenário são:
Web1: um aplicativo web com links para recursos de back-end que exigem que a identidade delegada do chamador inicial. Este aplicativo é criado com o ASP.NET.
Um serviço web que acessa um computador que executa o Microsoft SQL Server, que requer a identidade delegada do chamador inicial e do chamador imediato. Esse serviço é criado com Windows Communication Foundation (WCF).
sts1: um serviço de token de segurança (STS) que está na função de provedor de Federação e emite declarações esperados pelo aplicativo (web1). Ele estabeleceu confiança Fabrikam.com e também com o aplicativo.
sts2: um STS que está na função de provedor de identidade para Fabrikam.com e que fornece um ponto de extremidade que os funcionários da Fabrikam usa para autenticar. Ele estabeleceu confiança com Contoso.com, para que os funcionários da Fabrikam têm permissão para acessar recursos em Contoso.com.
Observe que o termo "token ActAs" se refere a um token emitido por um STS e que contém a identidade do usuário. A propriedade Delegate() contém a identidade do STS. Conforme mostrado na Figura 1, o fluxo neste cenário é:
O aplicativo Contoso é configurado para obter um token ActAs que contém a identidade do funcionário fabrikam e a identidade do chamador imediato na propriedade Delegate(). Daniel implementa essas alterações ao aplicativo.
O aplicativo Contoso é configurado para passar o token ActAs para o serviço de back-end. Daniel implementa essas alterações ao aplicativo.
O serviço da web Contoso é configurado para validar o token ActAs pelo sts1 chamada. Habilita o ADAM sts1 processar as solicitações de delegação.
Usuário de Fabrikam Frank acessa o aplicativo Contoso e é oferecido acesso para os recursos de back-end.
Autenticação federada
Autenticação federada permite que um security token service (STS) em um domínio de confiança para fornecer informações de autenticação para um STS no outro domínio de confiança, quando há uma relação de confiança entre os dois domínios. Um exemplo disso é mostrado na Figura 2.
Figura 2. Claims federation scenario
Um cliente no domínio de confiança Fabrikam envia uma solicitação a um aplicativo de terceira parte confiável no domínio de confiança da Contoso.
A terceira parte confiável redireciona o cliente para um STS no domínio de confiança da Contoso. Esse STS não tem conhecimento do cliente.
O STS Contoso redireciona o cliente para um STS no domínio de confiança Fabrikam, com o qual o domínio de confiança da Contoso tem uma relação de confiança.
O STS Fabrikam verifica a identidade do cliente e emite um token de segurança para o STS de Contoso.
O STS Contoso usa o token Fabrikam para criar seu próprio token, que ele envia para a confiança de terceiros.
A terceira parte confiável extrai declarações do cliente de token de segurança e faz com que uma decisão de autenticação.
Esse cenário descreve uma experiência de logon para um funcionário parceiro quando ela tenta acessar recursos do domínio de outro parceiro. Ela só tem que entrar uma vez. Há três grandes players em um cenário de federação: um provedor de identidade, um provedor de federação e uma parte confiável. O WIF oferece APIs para criar os três jogadores. A Figura 3 mostra um cenário típico de federação em que um funcionário da Fabrikam deseja acessar Contoso.com recursos sem precisar fazer logon novamente; ou seja, o funcionário da Fabrikam deseja usar o logon único. Figura 3. Claims identity delegation scenario
Os usuários de empresa fictícios participando neste cenário são:
Frank: Um funcionário da Fabrikam que deseje acessar os recursos da Contoso.
Daniel: Contoso desenvolvedor de aplicativo de quem implementa as alterações necessárias no aplicativo.
ADAM: O Contoso administrador de TI.
Os componentes envolvidos neste cenário são:
Web1: uma partes ordenação aplicativo web que é criado com o ASP.NET e controla o acesso às partes relevantes.
sts1: um STS que está na função de provedor de Federação em Contoso.com e emite declarações esperados pelo aplicativo (web1). Ele tenha estabelecido confiança com Fabrikam.com e está configurado para permitir o acesso aos funcionários da Fabrikam.
sts2: um STS que está na função do provedor de identidade no Fabrikam.com e fornece um ponto de extremidade ao qual o funcionário da Fabrikam é autenticado. Ele estabeleceu confiança com Contoso.com, para que os funcionários da Fabrikam têm permissão para acessar os recursos de Contoso.com.
Conforme mostrado na Figura 3, o fluxo neste cenário é:
Administrador da Contoso Adam configura a relação de confiança entre o aplicativo (terceira parte confiável) e o sts1.
Administrador da Contoso Adam configura a relação de confiança com sts2 como um provedor de identidade.
Administrador de Fabrikam Frank configura a relação de confiança com sts1 como um provedor de Federação e, em seguida, acessa o aplicativo.