Planejar métodos de autenticação (SharePoint Foundation 2010)

 

Aplica-se a: SharePoint Foundation 2010

Tópico modificado em: 2016-11-30

Este artigo descreve os métodos e os modos de autenticação aceitos pelo Microsoft SharePoint Foundation 2010. Autenticação é o processo de validação da identidade de um usuário. Após essa validação, o processo de autorização determina quais sites, conteúdo e outros recursos o usuário pode acessar. Modos de autenticação determinam como as contas são usadas internamente pelo SharePoint Foundation 2010.

Neste artigo:

• Métodos de autenticação com suporte

• Modos de autenticação — clássico ou baseado em declarações

• Implementando a autenticação do Windows

• Implementando a autenticação baseada em formulários

• Implementando a autenticação SAML baseada em token

• Escolhendo a autenticação para ambientes LDAP

• Planejando zonas para aplicativos Web

• Arquitetura para provedores baseados em tokens de SAML

Métodos de autenticação com suporte

O SharePoint Foundation 2010 dá suporte a métodos de autenticação incluídos em versões anteriores e também introduz a autenticação baseada em tokens, que tem como base o protocolo SAML (Security Assertion Markup Language) como opção. A tabela a seguir lista os métodos de autenticação com suporte.

Método	Exemplos	Observações
Windows	NTLM Kerberos Anônima Básica Digest	Neste momento, não há suporte para a autenticação de certificados do Windows.
Autenticação baseada em formulários	Protocolo LDAP Banco de dados SQL ou outros bancos de dados Provedores de associação e de função personalizados ou de terceiros
Autenticação baseada em tokens SAML	Active Directory Federation Services (AD FS) 2.0 Provedor de identidade de terceiros Protocolo LDAP	Só tem suporte com o SAML 1.1, que usa o protocolo WS-F PRP.

Modos de autenticação — clássico ou baseado em declarações

O SharePoint Foundation 2010 introduz a autenticação baseada em declarações, que tem como base o Windows Identity Foundation (WIF). Você pode usar qualquer um dos métodos de autenticação com suporte que possua autenticação baseada em declarações. Também pode usar a autenticação de modo clássico, que dá suporte à autenticação do Windows.

Ao criar um aplicativo Web, selecione um dos dois métodos de autenticação para uso com esse aplicativo: clássico ou baseado em declarações.

Se você selecionar o modo clássico, poderá implementar a autenticação do Windows. As contas de usuário serão tratadas pelo SharePoint Foundation 2010 como contas do AD DS (Serviços de Domínio Active Directory).

Se você selecionar a autenticação baseada em declarações, o SharePoint Foundation 2010 transformará automaticamente todas as contas de usuário em identidades de declarações, resultando em um token de declarações para cada usuário. O token de declarações contém as declarações que pertencem ao usuário. As contas do Windows serão convertidas em declarações do Windows. Os usuários associados baseados em formulários serão transformados em declarações de autenticação com base em formulários. As declarações incluídas em tokens baseados em SAML poderão ser usadas pelo SharePoint Foundation 2010. Além disso, os desenvolvedores e administradores do SharePoint poderão aumentar os tokens de usuário com mais declarações. Por exemplo, as contas de usuário do Windows e as contas baseadas em formulários poderão ser aumentadas com mais declarações usadas pelo SharePoint Foundation 2010.

O gráfico a seguir resume o suporte aos tipos de autenticação por cada modo de autenticação.

Tipo	Autenticação de modo clássico	Autenticação baseada em declarações
Windows NTLM Kerberos Anônima Básica Digest	Sim	Sim
Autenticação baseada em formulários LDAP Banco de dados SQL ou outros bancos de dados Provedores de associação e de função personalizados ou de terceiros	Não	Sim
Autenticação SAML baseada em token AD FS 2.0 Windows Live ID Provedor de identidade de terceiros LDAP	Não	Sim

Um farm do SharePoint Foundation 2010 pode incluir uma combinação de aplicativos Web que usam ambos os modos. Os serviços não diferenciam entre contas de usuário que sejam contas tradicionais do Windows e contas de declarações do Windows. Consequentemente, um usuário que pertença a sites configurados para usarem uma combinação de modos de autenticação obterá resultados de pesquisa de todos os sites aos quais tenha acesso, independentemente do modo configurado para aplicativos Web. O usuário não é interpretado como duas contas de usuário diferentes. Isso ocorre porque os serviços e os aplicativos de serviço usam identidades de declarações para comunicação entre farms, independentemente do modo selecionado para aplicativos Web e usuários.

Entretanto, os usuários que pertencem a mais de um repositório de usuários reconhecido por aplicativos Web do SharePoint Server são tratados como contas de usuário separadas, dependendo da identidade usada para fazer logon.

A seguinte diretriz poderá ajudá-lo a decidir qual modo selecionar:

• Para novas implementações do SharePoint Foundation 2010, use a autenticação baseada em declarações. Com essa opção, todos os tipos de autenticação com suporte estarão disponíveis para aplicativos Web. Não há nenhuma razão prática para selecionar a autenticação de modo clássico para novas implantações, mesmo que o ambiente inclua somente contas do Windows. A autenticação do Windows é implementada da mesma forma, independentemente do modo selecionado. Não há etapas adicionais para implementar a autenticação do Windows quando o modo de autenticação baseado em declarações é usado.

• Se você estiver atualizando uma solução de versão anterior para o SharePoint Foundation 2010 e essa solução só incluir contas do Windows, será possível usar a autenticação de modo clássico. Isso permite usar o mesmo design para zonas e URLs.

• Se você estiver atualizando uma solução que exija autenticação baseada em formulários, a única opção será atualizar para a autenticação baseada em declarações.

Se você estiver atualizando de uma versão anterior para o SharePoint Foundation 2010 e selecionar a autenticação baseada em declarações, tenha em mente as seguintes considerações:

• O código personalizado talvez precise ser atualizado. As Web Parts ou outro código personalizado, que dependa ou utilize identidades do Windows, deverão ser atualizados. Se o código personalizado usar identidades do Windows, use a autenticação de modo clássico até que o código seja atualizado.

• A migração de muitos usuários do Windows para identidades de declarações é demorada. Quando você alterar um aplicativo Web do modo clássico para o modo baseado em declarações durante o processo de atualização, deverá usar o Windows PowerShell para converter identidades do Windows em identidades de declarações. Esse processo pode ser lento. Verifique se há tempo suficiente durante o processo de atualização para concluir a tarefa.

• Alertas de pesquisa não têm suporte atualmente com a autenticação baseada em declarações.

A autenticação de declarações tem como base o WIF. O WIF é um conjunto de classes do .NET Framework que são usadas para implementar a identidade baseada em declarações. A autenticação de declarações depende de padrões, como o WSF e o WS-Trust, e de alguns protocolos, como o SAML. Para obter mais informações sobre a autenticação de declarações, consulte os seguintes recursos:

• Identidade baseada em declarações para Windows: uma introdução ao Active Directory Federation Services 2.0, ao Windows CardSpace 2.0 e ao Windows Identity Foundation (white paper) (https://go.microsoft.com/fwlink/?linkid=198942&clcid=0x416)

• Home page do Windows Identity Foundation (https://go.microsoft.com/fwlink/?linkid=198943&clcid=0x416)

Não é necessário ser um arquiteto de declarações para usar a autenticação de declarações no SharePoint Foundation 2010. Entretanto, a implementação de autenticação baseada em tokens de SAML requer coordenação com os administradores do ambiente baseado em declarações, conforme descrito posteriormente neste artigo.

Implementando a autenticação do Windows

O processo de implementação de métodos de autenticação do Windows é semelhante para ambos os modos de autenticação (clássico ou baseado em declarações). A escolha da autenticação baseada em declarações para um aplicativo Web não aumenta a complexidade da implementação de métodos de autenticação do Windows. Esta seção resume o processo para cada método.

Autenticação integrada do Windows — Kerberos e NTLM

O protocolo Kerberos e o protocolo NTLM são métodos de autenticação integrada do Windows, que permitem aos clientes autenticar de forma simplificada, sem a necessidade de fornecer credenciais. Os usuários que acessarem sites do SharePoint via Windows Explorer serão autenticados usando as credenciais com as quais o processo do Internet Explorer estiver sendo executado. Por padrão, essas credenciais são aquelas usadas para fazer logon no computador. Os serviços ou aplicativos que acessarem o SharePoint Server no modo de autenticação integrada do Windows tentarão autenticar usando as credenciais do thread em execução, que é a identidade do processo por padrão.

O NTLM é a forma mais simples de implementar a autenticação do Windows. Basta selecionar essa opção quando você estiver criando um aplicativo.

O protocolo Kerberos é um protocolo seguro que dá suporte à autenticação de tíquete. O uso do protocolo Kerberos requer a configuração adicional do ambiente. Para habilitar a autenticação Kerberos, os computadores cliente e servidor devem ter uma conexão confiável com o KDC (Centro de Distribuição de Chaves) do domínio. A configuração do protocolo Kerberos envolve a configuração de SPNs (nomes da entidade de serviço) no AD DS antes da instalação do SharePoint Foundation 2010.

As etapas a seguir resumem o processo de configuração da autenticação Kerberos:

1. Configure a autenticação Kerberos para comunicações SQL criando SPNs no AD DS para a conta de serviço do SQL Server.

2. Crie SPNs para aplicativos Web que usarão a autenticação Kerberos.

3. Instale o farm do SharePoint Foundation 2010.

4. Configure serviços específicos no farm para usar contas específicas.

5. Crie os aplicativos Web que usarão a autenticação Kerberos.

Para obter mais informações, consulte Planejar a autenticação Kerberos (SharePoint Server 2010).

Adicionalmente, para aplicativos Web com autenticação de declarações, as declarações para o serviço de token do Windows devem ser configuradas para delegação restrita. A delegação restrita é necessária para a conversão de declarações em tokens do Windows. Para ambientes que incluem várias florestas, uma confiança bidirecional entre florestas é necessária para o uso das declarações no serviço de token do Windows. Para obter mais informações sobre como configurar esse serviço, consulte Configure Kerberos authentication for the claims to Windows token service (SharePoint Server 2010).

A autenticação Kerberos permite a delegação de credenciais de cliente para acessar sistemas de dados back-end, o que requer configuração adicional dependendo do cenário. A tabela a seguir apresenta exemplos.

Cenário	Configuração adicional
Delegando uma identidade do cliente a um servidor back-end. Exibindo RSS feeds para conteúdo autenticado.	Configure a delegação restrita de Kerberos para computadores e contas de serviço.
Delegação de identidades para o Microsoft SQL Server Reporting Services (SSRS)	Configure SPNs para contas do SQL Server Reporting Services. Configure a delegação para o SQL Server Reporting Services.
Delegação de identidade do Serviços do Excel no SharePoint	Configure a delegação restrita para servidores que executam os Serviços do Excel. Configure a delegação restrita para a conta de serviço dos Serviços do Excel.

Para obter mais informações sobre como configurar a autenticação Kerberos, incluindo as etapas de configuração de cenários comuns, consulte o artigo sobre configuração da autenticação Kerberos para Produtos e Tecnologias do Microsoft SharePoint 2010 (white paper) (https://go.microsoft.com/fwlink/?linkid=197178&clcid=0x416).

Digest e Básica

A implementação da autenticação Digest e Básica requer a configuração desses métodos de autenticação diretamente no IIS (Serviços de Informações da Internet).

Implementando a autenticação baseada em formulários

A autenticação baseada em formulários é um sistema de gerenciamento de identidades que se baseia na autenticação de provedores de função e associação ASP.NET. No SharePoint Foundation 2010, a autenticação baseada em formulários só está disponível quando a autenticação baseada em declarações é usada.

A autenticação baseada em formulários pode ser usada com credenciais armazenadas no AD DS, em um banco de dados, como um banco de dados do SQL Server, ou em um repositório de dados LDAP, como o Novell eDirectory, o NDS (Novell Directory Services) ou o Sun ONE. A autenticação baseada em formulários permite a autenticação de usuários com base na validação da entrada de credenciais em um formulário de logon. As solicitações não autenticadas são redirecionadas para uma página de logon, onde o usuário deve fornecer credenciais válidas e enviar o formulário. Se a solicitação puder ser autenticada, o sistema emitirá um cookie contendo uma chave para restabelecer a identidade para solicitações subsequentes.

Para usar a autenticação baseada em formulários de forma a autenticar usuários em um sistema de gerenciamento de identidades que não se baseie no Windows ou que seja externo, registre o provedor de associação e o gerenciador de funções no arquivo Web.config. O registro do gerenciador de funções é um novo requisito do SharePoint Foundation 2010. Na versão anterior, isso era opcional. O SharePoint Foundation 2010 usa a interface padrão do gerenciador de funções ASP.NET para coletar informações de grupos sobre o usuário atual. Cada função ASP.NET é tratada como um grupo de domínios pelo processo de autorização no SharePoint Foundation 2010. Registre os gerenciadores de funções no arquivo Web.config da mesma forma que você registra os provedores de associação para autenticação.

Para gerenciar usuários associados ou funções no site da Administração Central do SharePoint, você deve registrar o provedor de associação e o gerenciador de funções no arquivo Web.config do site da Administração Central. Também é necessário registrar o provedor de associação e o gerenciador de funções no arquivo Web.config do aplicativo Web que hospeda o conteúdo.

Para obter mais informações sobre como configurar a autenticação baseada em formulários, consulte os seguintes recursos:

• Artigo do TechNet: Configurar a autenticação baseada em formulários para um aplicativo Web baseado em declarações (SharePoint Server 2010)

• Artigo de blog do MSDN sobre autenticação baseada em declarações "Cheat Sheet" (Parte 1) (https://go.microsoft.com/fwlink/?linkid=198944&clcid=0x416)

• Artigo do MSDN sobre autenticação de formulários em Produtos e Tecnologias do SharePoint (Parte 2): exemplos de provedores de função e associação (https://go.microsoft.com/fwlink/?linkid=198945&clcid=0x416)

Implementando a autenticação baseada em tokens de SAML

A autenticação baseada em tokens de SAML requer coordenação com os administradores de um ambiente baseado em declarações, seja o seu próprio ambiente interno ou um ambiente de parceiro. O AD FS 2.0 é um exemplo de ambiente baseado em declarações.

Um ambiente baseado em declarações inclui um IP-STS (serviço de token de segurança de provedor de identidade). O IP-STS emite tokens de SAML em nome dos usuários que estão incluídos no diretório de usuários associado. Os tokens podem incluir qualquer número de declarações sobre um usuário, como um nome de usuário e os grupos aos quais esse usuário pertence.

O SharePoint Foundation 2010 aproveita as vantagens das declarações incluídas em tokens fornecidos por um IP-STS para autorizar usuários. Em ambientes de declarações, um aplicativo que aceita tokens de SAML é conhecido como RP-STS (STS de terceira parte confiável). Um aplicativo de terceira parte confiável recebe o token de SAML e usa as declarações nele contidas para decidir se concede ao cliente acesso ao recurso solicitado. No Produtos do SharePoint 2010, cada aplicativo Web configurado para usar um provedor SAML é adicionado ao servidor IP-STS como uma entrada RP-STS separada. Um farm do SharePoint pode incluir várias entradas RP-STS.

A implementação da autenticação baseada em tokens de SAML com o Produtos do SharePoint 2010 envolve os seguintes processos de planejamento avançado:

1. Exportar o certificado de autenticação de tokens do IP-STS. Esse certificado é conhecido como ImportTrustCertificate. Copie o certificado para um computador servidor no farm do SharePoint Foundation 2010.

2. Definir a declaração que será usada como o identificador exclusivo do usuário. Isso é conhecido como a declaração da identidade. Muitos exemplos desse processo usam o nome de email do usuário como identificador exclusivo. Coordene-se com o administrador do IP-STS para determinar o identificador correto, pois somente o proprietário do IP-STS sabe o valor no token que será sempre exclusivo por usuário. A identificação do identificador exclusivo do usuário faz parte do processo de mapeamento de declarações. Mapeamentos de declarações são criados com o Windows PowerShell.

3. Definir mapeamentos de declarações adicionais. Defina as declarações adicionais do token de entrada que serão usadas pelo farm do SharePoint Foundation 2010. As funções de usuário são um exemplo de declaração que pode ser usada para recursos de permissão no farm do SharePoint Foundation 2010. Todas as declarações de um token de entrada que não possuam um mapeamento serão descartadas.

4. Criar um novo provedor de autenticação via Windows PowerShell para importar o certificado de autenticação de tokens. Esse processo cria SPTrustedIdentityTokenIssuer. Durante esse processo, especifique a declaração de identidade e as declarações adicionais que você mapeou. Será também necessário criar e especificar um realm associado ao primeiro aplicativo Web do SharePoint que está sendo configurado para autenticação baseada em tokens de SAML. Após a criação de SPTrustedIdentityTokenIssuer, será possível criar e adicionar mais realms a outros aplicativos Web do SharePoint. É assim que se configuram vários aplicativos Web para usar o mesmo SPTrustedIdentityTokenIssuer.

5. Para cada realm adicionado a SPTrustedIdentityTokenIssuer, é necessário criar uma entrada RP-STS no IP-STS. Isso pode ser feito antes que o aplicativo Web do SharePoint seja criado. De qualquer forma, planeje a URL antes de criar os aplicativos Web.

6. Criar um novo aplicativo Web do SharePoint e configurá-lo para usar o provedor de autenticação recém-criado. O provedor de autenticação será exibido como opção na Administração Central quando o modo de declarações estiver selecionado para o aplicativo Web.

É possível configurar vários provedores de autenticação baseada em tokens de SAML. Entretanto, você só pode usar um certificado de autenticação de tokens uma única vez em um farm. Todos os provedores configurados serão exibidos como opções na Administração Central. Declarações de diferentes ambientes STS confiáveis não entrarão em conflito.

Se você estiver implementando a autenticação baseada em tokens de SAML com uma empresa parceira e seu próprio ambiente incluir um IP-STS, convém trabalhar com o administrador do seu ambiente interno de declarações para estabelecer uma relação confiável do IP-STS interno com o STS parceiro. Essa abordagem não requer a adição de outro provedor de autenticação ao farm do SharePoint Foundation 2010. Ela também permite que seus administradores de declarações gerenciem todo o ambiente de declarações.

Observação

Se você usar a autenticação baseada em tokens de SAML com o AD FS em um farm do SharePoint Foundation 2010 que tenha vários servidores Web em uma configuração de balanceamento de carga, o desempenho e a funcionalidade da exibição de páginas da Web do cliente poderão ser afetados. Quando o AD FS fornece o token de autenticação ao cliente, esse token é submetido ao SharePoint Foundation 2010 para cada elemento de página com permissão restrita. Se a solução de balanceamento de carga não estiver usando afinidade, cada elemento protegido será autenticado em mais de um servidor do SharePoint Foundation 2010, o que pode resultar na rejeição do token. Após o token ser rejeitado, o SharePoint Foundation 2010 redirecionará o cliente para reautenticação no servidor AD FS. Depois disso, um servidor AD FS poderá rejeitar várias solicitações feitas em um período de tempo curto. Esse comportamento serve originalmente para proteger contra um ataque de negação de serviço. Se o desempenho for negativamente afetado ou se as páginas não forem carregadas completamente, considere definir o balanceamento de carga para uma única afinidade. Isso isola as solicitações feitas aos tokens de SAML em um único servidor Web.

Para obter mais informações sobre como configurar a autenticação baseada em tokens de SAML, consulte os seguintes recursos:

• Artigo TechNet: Configurar a autenticação usando um token de segurança SAML (SharePoint Server 2010)

• Artigo de blog do MSDN sobre autenticação baseada em declarações "Cheat Sheet" (Parte 2) (https://go.microsoft.com/fwlink/?linkid=198946&clcid=0x416)

• Artigo de blog do TechNet sobre considerações de planejamento da autenticação baseada em declarações no SharePoint 2010 (https://go.microsoft.com/fwlink/?linkid=198947&clcid=0x416)

• Artigo de blog do TechNet sobre a criação de uma declaração de identidade e função para um aplicativo de autenticação de declarações do SharePoint 2010 (https://go.microsoft.com/fwlink/?linkid=198948&clcid=0x416)

• Artigo de blog do TechNet sobre como criar vários aplicativos Web de autenticação de declarações em um único farm do SharePoint 2010 (https://go.microsoft.com/fwlink/?linkid=198949&clcid=0x416)

Escolhendo a autenticação para ambientes LDAP

Ambientes LDAP podem ser implementados por autenticação baseada em formulários ou por autenticação baseada em tokens de SAML. É recomendável usar a autenticação baseada em formulários porque ela é menos complexa. Entretanto, se o ambiente incluir suporte para WS-Federation 1.1 e SAML Token 1.1, convém usar o SAML. A sincronização de perfis não tem suporte em provedores LDAP que não estejam associados ao ADFS 2.0.

Planejando zonas para aplicativos Web

Zonas representam diferentes caminhos lógicos para ganhar acesso aos mesmos sites em um aplicativo Web. Cada aplicativo Web pode incluir até cinco zonas. Quando um aplicativo Web é criado, a zona padrão é criada. Para criar zonas adicionais, estenda o aplicativo Web e selecione um dos nomes de zona restantes: intranet, extranet, Internet ou personalizado.

Em versões anteriores, zonas são usadas para implementar diferentes tipos de autenticação para usuários provenientes de diferentes redes ou provedores de autenticação. Na versão atual, a autenticação de declarações permite que vários tipos de autenticação sejam implementados na mesma zona.

O planejamento de zonas depende de qual dos modos a seguir será selecionado para um aplicativo Web:

• Modo clássico — de maneira semelhante às versões anteriores, somente um tipo de autenticação pode ser implementado por zona. Entretanto, na versão atual, somente a autenticação do Windows pode ser implementada quando o modo clássico é selecionado. Consequentemente, várias zonas podem ser usadas somente para implementar vários tipos de autenticação do Windows ou para implementar o mesmo tipo de autenticação do Windows em diferentes repositórios do Active Directory.

• Autenticação de declarações — vários provedores de autenticação podem ser implementados em uma única zona. Várias zonas também podem ser usadas.

Implementando mais de um tipo de autenticação em uma única zona

Se você estiver usando a autenticação de declarações e implementando mais de um tipo de autenticação, convém implementar vários tipos de autenticação na zona padrão. Isso resulta na mesma URL para todos os usuários.

Quando você estiver implementando vários tipos de autenticação na mesma zona, as seguintes restrições serão aplicáveis:

• Somente uma instância da autenticação baseada em formulários pode ser implementada em uma zona.

• A Administração Central permite usar um método de autenticação integrada do Windows e a autenticação básica ao mesmo tempo. Caso contrário, não será possível implementar mais de um tipo de autenticação do Windows em uma zona.

Se vários provedores de autenticação baseada em tokens de SAML forem configurados para um farm, todos eles serão exibidos como opções quando você criar um aplicativo Web ou uma nova zona. Vários provedores de SAML podem ser configurados na mesma zona.

O diagrama a seguir ilustra vários tipos de autenticação implementados na zona padrão de um site de colaboração de parceiro.

No diagrama, usuários de diferentes repositórios de diretórios acessam o site de parceiro usando a mesma URL. Uma caixa tracejada ao redor das empresas parceiras mostra a relação entre o diretório do usuário e o tipo de autenticação configurado na zona padrão. Para obter mais informações sobre esse exemplo de design, consulte Exemplo de design: implantação corporativa (SharePoint Server 2010).

Planejando o rastreamento de conteúdo

O componente de rastreamento requer acesso ao conteúdo usando NTLM. Pelo menos uma zona deve ser configurada para usar a autenticação NTLM. Se a autenticação NTLM não estiver configurada na zona padrão, o componente de rastreamento poderá usar outra zona que esteja configurada para usar essa autenticação.

Implementando mais de uma zona

Se você pretende implementar mais de uma zona para um aplicativo Web, siga estas diretrizes:

• Use a zona padrão para implementar as configurações de autenticação mais seguras. Se não for possível associar uma solicitação a uma zona específica, as configurações de autenticação e outras diretivas de segurança da zona padrão serão aplicadas. A zona padrão é aquela gerada na criação inicial de um aplicativo Web. Geralmente, as configurações de autenticação mais seguras são as criadas para acesso do usuário final. Consequentemente, os usuários finais podem acessar a zona padrão.

• Use o número mínimo de zonas necessárias para fornecer acesso aos usuários. Cada zona é associada a um novo site e domínio do IIS para acessar o aplicativo Web. Adicione novos pontos de acesso somente quando forem necessários.

• Verifique se há pelo menos uma zona configurada para usar a autenticação NTLM para o componente de rastreamento. Não crie uma zona dedicada para o componente de índice se ela não for necessária.

O diagrama a seguir ilustra várias zonas que são implementadas para acomodar diferentes tipos de autenticação para um site de colaboração de parceiro.

No diagrama, a zona padrão é usada para funcionários remotos. Cada zona tem uma URL diferente associada. Os funcionários utilizam uma zona diferente dependendo de onde estão trabalhando: no escritório ou remotamente. Para obter mais informações sobre esse exemplo de design, consulte Exemplo de design: implantação corporativa (SharePoint Server 2010).

Arquitetura para provedores baseados em tokens de SAML

A arquitetura para implementar provedores baseados em tokens de SAML inclui os seguintes componentes:

Serviço de token de segurança do SharePoint   Esse serviço cria os tokens de SAML que são utilizados pelo farm. O serviço é automaticamente criado e iniciado em todos os servidores de um farm. Ele é usado para comunicação entre farms, pois toda essa comunicação usa a autenticação de declarações. Ele também é utilizado para métodos de autenticação implementados para aplicativos Web que usam autenticação de declarações, incluindo a autenticação do Windows, a autenticação baseada em formulários e a autenticação baseada em tokens de SAML. Você deve configurar o serviço de token de segurança durante o processo de implantação. Para obter mais informações, consulte Configurar o serviço de token de segurança (SharePoint Server 2010).

Certificado de autenticação de tokens (ImportTrustCertificate)   Esse é o certificado que é exportado de um IP-STS. O certificado é copiado para um servidor no farm. Após usar o certificado para criar um SPTrustedIdentityTokenIssuer, você não pode usá-lo novamente para criar outro. Se quiser usar o certificado para criar outro SPTrustedIdentityTokenIssuer, primeiro você deverá excluir aquele já existente. Antes da exclusão, você deve desassociá-lo de todos os aplicativos Web que o estejam utilizando.

Declaração de identidade   A declaração de identidade é a declaração originada de um token de SAML que é o identificador exclusivo do usuário. Somente o proprietário do IP-STS sabe qual valor no token será sempre exclusivo para cada usuário. A declaração de identidade é criada como um mapeamento de declarações regular durante o processo de mapeamento de todas as declarações desejadas. A declaração que funciona como declaração de identidade é declarada quando o SPTrustedIdentityTokenIssuer é criado.

Outras declarações   Consistem em declarações adicionais de um tíquete de SAML que descrevem usuários. Podem incluir funções de usuário, grupos de usuários ou outros tipos de declarações, como vencimento. Todos os mapeamentos de declarações são criados como objetos que são replicados entre os servidores em um farm do SharePoint Foundation.

Realm   Na arquitetura de declarações do SharePoint, o URI ou a URL associado a um aplicativo Web do SharePoint que está configurado para usar um provedor baseado em token de SAML representa um realm. Ao criar um provedor de autenticação baseado em SAML no farm, você pode especificar os realms ou as URLs de aplicativos Web que deseja que o IP-STS reconheça, um de cada vez. O primeiro realm é especificado quando você cria o SPTrustedIdentityTokenIssuer. Realms adicionais podem ser adicionados após a criação de SPTrustedIdentityTokenIssuer. Realms são especificados com uma sintaxe semelhante a: $realm = "urn:sharepoint:meus_sites". Após adicionar o domínio ao SPTrustedIdentityTokenIssuer, você deve criar uma relação de confiança do RP-STS com o realm no servidor IP-STS. Esse processo envolve a especificação da URL para o aplicativo Web.

SPTrustedIdentityTokenIssuer   Esse é o objeto criado no farm do SharePoint que inclui os valores necessários para se comunicar com e receber tokens do STS-IP. Ao criar SPTrustedIdentityTokenIssuer, você especifica o certificado de autenticação de tokens a ser usado, o primeiro realm, a declaração que representa a declaração da identidade e qualquer declaração adicional. Só é possível associar um certificado de autenticação de tokens de um STS a um SPTrustedIdentityTokenIssuer. No entanto, após criar o SPTrustedIdentityTokenIssuer, você pode adicionar realms a outros aplicativos Web. Depois que um realm é adicionado a SPTrustedIdentityTokenIssuer, ele também deve ser adicionado ao STS-IP como uma terceira parte confiável. O objeto SPTrustedIdentityTokenIssuer é replicado entre servidores no farm do SharePoint Foundation.

Serviço de token de segurança de terceira parte confiável (RP-STS)   No SharePoint Foundation 2010, cada aplicativo Web que está configurado para usar um provedor de SAML é adicionado ao servidor IP-STS como uma entrada de RP-STS. Um farm do SharePoint Foundation pode incluir várias entradas de RP-STS.

Serviço de token de segurança de provedor de identidade (IP-STS)   Esse é o serviço de token seguro no ambiente de declarações que emite tokens de SAML em nome dos usuários que estão incluídos no diretório de usuários associado.

O diagrama a seguir ilustra a arquitetura de declarações do Produtos do SharePoint 2010.

O objeto SPTrustedIdentityTokenIssuer é criado com o uso de vários parâmetros. O diagrama a seguir ilustra os principais parâmetros.

Conforme ilustrado pelo diagrama, um SPTrustedIdentityTokenIssuer pode incluir somente uma declaração de identidade, um parâmetro SignInURL e um parâmetro Wreply. No entanto, pode incluir vários realms e vários mapeamentos de declarações. O parâmetro SignInURL especifica a URL à qual redirecionar uma solicitação do usuário para autenticação no IP-STS. Alguns servidores IP-STS exigem o parâmetro Wreply, que é definido como verdadeiro ou falso, sendo falso por padrão. Só use o parâmetro Wreply se ele for exigido pelo STS-IP.