Identidade baseada em declarações e conceitos do SharePoint
Modelo de identidade baseada em declarações
Quando você criar aplicativos com reconhecimento de declarações, o usuário apresenta uma identidade para o aplicativo como um conjunto de declarações. Uma declaração pode ser o nome do usuário, outro pode ter um endereço de e-mail. A idéia aqui é que um sistema de identidade externa está configurado para atribuir o aplicativo todas as informações necessárias sobre o usuário com cada solicitação, juntamente com a criptografia garantia de que os dados de identidade recebidos pelo seu aplicativo vem de uma fonte confiável.
Sob esse modelo, serviço single sign-on é muito mais fácil atingir e seu aplicativo não é mais responsável pelo seguinte:
Autenticação de usuários
Armazenando contas de usuário e senhas
Chamar para diretórios corporativos para pesquisar os detalhes de identidade do usuário
Integrando com sistemas de identidade de outras plataformas ou empresas
Com esse modelo, seu aplicativo toma decisões relacionadas à identidade baseadas em declarações fornecidas pelo usuário. Isso pode ser qualquer coisa de personalização do aplicativo simples com o nome do usuário, para autorizar o usuário para acessar recursos do maiores valor e recursos em sua aplicação.
As seções a seguir apresentam a terminologia e os conceitos para ajudá-lo a entender a arquitetura de identidade baseada em declarações.
Identidade: Um conjunto de atributos que descrevem uma entidade
A identidade é um conjunto de atributos que descrevem um usuário ou outra entidade, em um sistema que você deseja proteger.
Declaração: Uma parte das informações de identidade
Pense em uma declaração como uma parte das informações de identidade (por exemplo, nome, endereço de e-mail, idade ou associação na função de vendas). As declarações mais seu aplicativo recebe, quanto mais você souber sobre o usuário. Elas são denominadas "declarações", em vez de "atributos", como normalmente é usado na descrição de diretórios da empresa, devido ao método de entrega. Nesse modelo, o aplicativo não procurar os atributos de usuário em um diretório. Em vez disso, o usuário fornece declarações ao seu aplicativo, e seu aplicativo examina-los. Cada declaração é feita por um emissor e confiar a declaração apenas tanto quanto você confia no emissor. Por exemplo, você pode confiar uma declaração feita pelo controlador de domínio da empresa mais do que você confiar em uma declaração feita pelo usuário.
Token de segurança: um conjunto serializado de declarações
O usuário fornece um conjunto de declarações para o seu aplicativo com uma solicitação. Em um serviço da web, essas declarações são feitas no cabeçalho de segurança do envelope SOAP. Em um aplicativo web com base em navegador, as declarações chegam por meio de um HTTP POST do navegador do usuário e podem posteriormente ser armazenada em cache em um cookie se uma sessão for desejada. Independentemente de como essas declarações chegam, eles devem ser serializados. Um token de segurança é um conjunto serializado de declarações que seja assinado digitalmente pela autoridade emissora. A assinatura é importante: oferece garantia de que o usuário não apenas fazer declarações e enviá-las para você. Em situações de baixa segurança em que a criptografia não é necessário ou desejado, você pode usar os símbolos não assinados, mas esse cenário não é descrito neste artigo.
Um dos recursos principais do Windows Identity Foundation (WIF) é a capacidade de criar e ler os tokens de segurança. WIF e o Microsoft.NET Framework lidar com todo o trabalho de criptografia e apresentam seu aplicativo com um conjunto de declarações que ele pode ser lido.
security token service (STS)
Um serviço de token de segurança (STS) é a estrutura que se baseia, sinais e problemas de tokens de segurança de acordo com os protocolos interoperáveis discutidos na seção "Padrões" deste artigo. Há muito trabalho que vai para a implementação desses protocolos, mas WIF faz todo esse trabalho por você, tornando possível para alguém que não seja um protocolos especializados para subir um STS e executando com pouco esforço.
WIF torna mais fácil criar o seu próprio STS. Cabe a você descobrir uma maneira de implementar a lógica ou regras que aplicarão (geralmente chamado de diretiva de segurança).
Autoridade de emissão
Há muitos tipos diferentes de emitir autoridades, dos controladores de domínio que emitem tíquetes Kerberos, para autoridades de certificação que emitem certificados x. 509. O tipo específico de autoridade abordados problemas neste artigo tokens de segurança que contêm as declarações. Esta autoridade de emissão é um aplicativo da web ou serviço da web que emite tokens de segurança. Ele deve ser capaz de emitir as reivindicações adequadas dadas o destino contar festa e o usuário que está fazendo a solicitação e pode ser responsável por interagir com armazenamentos de usuário para procurar declarações e autenticar usuários.
Qualquer autoridade que escolher, ela desempenha um papel central na sua solução de identidade. Quando você pode fatorar autenticação fora do seu aplicativo baseando-se em declarações, estão passando a responsabilidade para a autoridade e perguntando para autenticar usuários em seu nome.
Partes confiáveis
Quando você cria um aplicativo que dependa de declarações, você está criando um aplicativo de terceiros confiante. Sinônimos de uma terceira parte confiável incluem "aplicativo com reconhecimento de declarações" e "aplicativos baseados em declarações". Aplicativos da Web e serviços da web podem ser partes confiantes.
Um aplicativo de terceiros terceira consome tokens emitidos por um STS e extrai declarações de tokens para usá-los para a identidade de tarefas relacionadas. Os STS suporta dois tipos de contar com o aplicativo de terceiros: aplicativos da web de ASP.NET e Windows Communication Foundation (WCF) web services.
Padrões
Para tornar tudo isso interoperáveis, vários WS-* padrões são usados no cenário anterior. Política é recuperada usando o WS-MetadataExchange e a própria diretiva é estruturada de acordo com a especificação WS-Policy. O STS expõe pontos de extremidade que implementam a especificação WS-Trust, que descreve como solicitar e receber tokens de segurança. Os serviços de token de segurança a maioria dos tokens de problema hoje formatadas com marcação linguagem SAML (Security Assertion). SAML é um vocabulário XML reconhecidos no mercado que pode ser usado para representar declarações de forma interoperável. Ou, em uma situação de várias plataformas, isso permite a comunicação com um STS em uma plataforma totalmente diferente e atingir o logon único em todos os aplicativos, independentemente da plataforma.
Aplicativos baseados em navegador
Clientes inteligentes não são os únicos que podem utilizar o modelo de identidade baseada em declarações. Aplicativos baseados em navegador (também conhecidos como os clientes passivos) também podem usá-lo. O cenário a seguir descreve como isso funciona.
Primeiro, o usuário aponta um navegador em um aplicativo da web compatível com declarações (o aplicativo de terceiros confiável). O aplicativo da web redireciona o navegador para o STS para que o usuário poderá ser autenticado. O STS é hospedado em um aplicativo web simples que lê a solicitação de entrada, autentica o usuário por meio de mecanismos padrão de HTTP e cria um token SAML e responde com uma parte do código de ECMAScript (JavaScript, JScript) que faz com que o navegador iniciar um HTTP POST que envia o token SAML volta para a parte confiante. O corpo desta POSTAGEM contém as declarações solicitada a parte confiante. Neste ponto, é comum para a parte confiante empacotar as declarações em um cookie para que o usuário não precisa ser redirecionado para cada solicitação.
Claims to Windows Token Service (c2WTS)
O Claims to Windows Token Service (c2WTS) é um recurso de Windows Identity Foundation (WIF). O c2WTS extrai declarações de nome principal (UPN) do usuário de tokens de segurança não-Windows, como tokens SAML e x. 509 e gera os tokens de segurança do Windows de nível de representação. Isso permite que um aplicativo de terceiros confiável representar o usuário. Isso deve ser necessária para acessar recursos de back-end, como Microsoft SQL Servers, externas ao computador que executa o aplicativo parte confiante.
O c2WTS é um serviço do Windows que é instalado como parte do WIF. Por motivos de segurança, o c2WTS funciona apenas em uma base opt-in. Ele deve ser iniciado manualmente e ele é executado como a conta sistema local. Um administrador deve configurar manualmente o c2WTS com uma lista de chamadores permitidos. Por padrão, a lista está vazia.
Se seu aplicativo parte confiante é executado como a conta sistema local, não é necessário usar o c2WTS. Mas, se seu aplicativo parte confiante é executado como a conta Serviço de rede ou um aplicativo de ASP.NET , por exemplo, pode precisar usar o c2WTS para acessar recursos em outro computador.
Suponha que você tenha uma web farm que consiste em um servidor que executa um aplicativo ASP.NET , que acessa um banco de dados SQL em um servidor back-end. Deseja tornar este aplicativo compatível com declarações. Mas o aplicativo não pode acessar o banco de dados SQL usando a declaração que ele recebe de um STS. Em vez disso, ele usa o c2WTS para converter a declaração de UPN em um token de segurança do Windows. Isso permite que ele acesse o banco de dados SQL.
Observação
[!OBSERVAçãO] Para permitir que um aplicativo acessar recursos em um servidor diferente, um administrador de domínio deve configurar o serviço de diretório do Active Directory para habilitar a delegação restrita. Para obter informações sobre como habilitar restrita a delegação, consulte como: transição de protocolo de uso e restrita eelegation no ASP.NET 2.0.