Plano para métodos de autenticação do usuário no SharePoint Server
APLICA-SE A:
2013 2016 2019 Subscription Edition 
SharePoint no Microsoft 365
Observação
Os métodos de autenticação de utilizador mencionados aqui aplicam-se ao SharePoint Server 2013, SharePoint Server 2016, SharePoint Server 2019 e SharePoint Server Subscription Edition.
Aprenda sobre os tipos e métodos de autenticação de usuário com suporte do SharePoint Server, e como determinar quais devem ser usados para zonas e aplicativos da Web.
Saiba mais sobre a autenticação do SharePoint no Microsoft 365.
Observação
No SharePoint Server Subscription Edition, suportamos agora a autenticação OIDC 1.0. Para obter mais informações sobre como trabalhar com este novo tipo de autenticação, veja Autenticação do OpenID Connect 1.0.
Introdução
Autenticação é a validação da identidade de um usuário em um provedor de autenticação, que é um diretório ou banco de dados que contém as credenciais do usuário e pode confirmar se ele as enviou corretamente. Um exemplo de um provedor de autenticação é o Serviços de Domínio do Active Directory (AD DS). O provedor de autenticação também é chamado de diretório de usuários e repositório de atributos.
Um método de autenticação é uma troca específica de credenciais de conta e outras informações que afirmam a identidade de um utilizador. O resultado do método de autenticação prova que, normalmente na forma de um token que contém declarações, um provedor de autenticação autenticou um usuário.
Um tipo de autenticação é uma maneira específica de validar as credenciais em um ou mais provedores de autenticação, às vezes usando um protocolo padrão do setor. Um tipo de autenticação pode usar diversos métodos.
Depois que a identidade de um usuário é validada, o processo de autorização determina quais sites, conteúdo e outros recursos ele pode acessar.
O seu planeamento para tipos e métodos de autenticação de utilizador deve determinar:
Os tipos e métodos de autenticação de usuário para cada aplicativo e zona da web
A infraestrutura de autenticação necessária para suportar os tipos e métodos determinados de autenticação
Observação
A autenticação do modo clássico do Windows já não é suportada no SharePoint Server 2016, SharePoint Server 2019 e SharePoint Server Subscription Edition.
Autenticação baseada em declarações
A identidade do usuário no AD DS é baseada em uma conta de usuário. Para o sucesso da autenticação, o usuário fornece o nome da conta e a prova de conhecimento da senha. Para determinar o acesso aos recursos, os aplicativos podem ter que consultar o AD DS para ver os atributos da conta e outras informações, como a associação do grupo ou a função na rede. Embora esta funcionalidade funcione bem para ambientes windows, não aumenta horizontalmente para fornecedores de autenticação de terceiros e ambientes multi-fornecedores que suportem modelos de computação baseados na Internet, parceiros ou na cloud.
Com as identidades baseadas em declarações, o usuário obtém um token de segurança com assinatura digital, de um fornecedor de identidade comumente confiável. O token contém uma série de declarações. Cada afirmação representa um item específico de dados sobre os utilizadores, como os respetivos nomes, associações a grupos e função na rede. A autenticação baseada nas declarações utiliza tecnologias e infraestruturas de identidade baseadas em declarações para autenticar o usuário. Os aplicativos que suportam essa autenticação obtêm um token de segurança do usuário, e não as credenciais, e usam as informações dentro das declarações para determinar o acesso aos recursos. Nenhuma consulta separada a um serviço de diretório como o AD DS é necessária.
A autenticação baseada em declarações no Windows é criada sobre o Windows Identity Foundation (WIF), um conjunto de classes do .NET Framework que são usadas para implementar a identidade baseada em declarações. Esse tipo de autenticação depende de padrões como WS-Federation, WS-Trust e protocolos como o SAML.
Para saber mais sobre a autenticação baseada em declarações, confira os recursos a seguir:
Devido ao uso disseminado da autenticação baseada em declarações para a autenticação de usuário, de servidor-para-servidor e de aplicativos, recomendamos esse tipo de autenticação para todos os aplicativos e zonas da web de um farm do SharePoint Server. Para saber mais, confira Plano de autenticação servidor-para-servidor no SharePoint Server. Quando você usa a autenticação baseada em declarações, todos os métodos de autenticação com suporte ficam disponíveis para seus aplicativos Web, e você pode aproveitar os novos recursos e cenários do SharePoint Server que usam a autenticação de servidor-para-servidor e de aplicativos.
Para a autenticação baseada em declarações, o SharePoint Server altera automaticamente todas as contas de usuário para identidades de declarações. Esta alteração resulta num token de segurança (também conhecido como token de afirmações) para cada utilizador. Ele contém as declarações que pertencem ao usuário. As contas do Windows são convertidas em declarações do Windows. Os usuários da associação baseada em formulários são transformados em declarações de autenticação baseadas em formulário. O SharePoint Server pode usar declarações incluídas em tokens baseados no SAML. Além disso, os programadores e administradores do SharePoint podem aumentar os tokens de utilizador com mais afirmações. Por exemplo, as contas de utilizador do Windows e as contas baseadas em formulários podem ser aumentadas com afirmações adicionais que são utilizadas pelo SharePoint Server.
Não tem de ser um arquiteto de afirmações para utilizar a autenticação baseada em afirmações no SharePoint Server. No entanto, implementar a autenticação baseada em tokens SAML exige a coordenação com os administradores do seu ambiente baseado em declarações, conforme descrito em Planejar a autenticação baseada em tokens do SAML.
Autenticação de modo clássico no SharePoint Server 2013
No SharePoint 2013, quando você cria um aplicativo da web na Administração central, pode especificar somente tipos e métodos para a autenticação baseada em declarações. Nas versões prévias do SharePoint, você poderia configurar também a autenticação de modo clássico para os aplicativos da web na Administração central. A autenticação de modo clássico usa a autenticação do Windows e o SharePoint 2013 trata as contas de usuário como contas do AD DS.
Para configurar um aplicativo da web para usar a autenticação de modo clássico, use o cmdlet New-SPWebApplication PowerShell para criá-lo. Os aplicativos da Web do Produtos do SharePoint 2010 que são configurados para a autenticação de modo clássico retêm as configurações de autenticação quando você atualiza para o SharePoint 2013. No entanto, recomendamos migrar seus aplicativos da web para a autenticação baseada em declarações antes de atualizar para o SharePoint 2013.
Um farm do SharePoint 2013 pode incluir um mix de aplicativos da web que usam ambos os modos. Alguns serviços não diferenciam entre contas de utilizador que são contas tradicionais do Windows e contas de afirmações do Windows.
Para saber mais sobre como migrar antes de atualizar, confira Migrar do modo clássico para a autenticação baseada em declarações.
Para saber mais sobre como migrar depois de atualizar, confira Migrate from classic-mode to claims-based authentication in SharePoint Server.
Para obter informações sobre como criar aplicativos da web que usam a autenticação de modo clássico no SharePoint 2013, confira Criar aplicativos da web que usam a autenticação de modo clássico no SharePoint Server. Não pode migrar uma aplicação Web que utilize autenticação baseada em afirmações para utilizar a autenticação de modo clássico.
Importante
O Office Online pode ser usado somente por aplicativos da web do SharePoint 2013 que usam autenticação com base em declarações. O processamento e a edição do Office Online não funcionarão em aplicativos da web do SharePoint 2013 que usam a autenticação no modo clássico. Se você migrar os aplicativos da web do SharePoint 2010 que usam a autenticação no modo clássico para SharePoint 2013, será necessário migrá-los para autenticação com base em declarações a fim de permitir que eles funcionem com o Office Online.
Tipos e métodos de autenticação suportados
O SharePoint Server suporta vários métodos de autenticação e fornecedores de autenticação para os seguintes tipos de autenticação:
Autenticação do Windows
Autenticação baseada em formulários
Autenticação baseada em tokens do SAML
Autenticação do Windows
O tipo de autenticação do Windows aproveita as vantagens do seu provedor de autenticação existente do Windows (AD DS) e os protocolos de autenticação que um ambiente de domínio do Windows utiliza para validar as credenciais dos clientes conectados. O método de autenticação do Windows, que é utilizado pela autenticação baseada em ambas as afirmações, inclui:
NTLM
Kerberos
Digest
Básica
Para saber mais, confira Planeje a autenticação do Windows neste artigo.
Assista ao vídeo de autenticação de declarações do Windows no SharePoint 2013 e no SharePoint Server 2016
Embora não seja um tipo de autenticação do Windows, o SharePoint Server também oferece suporte à autenticação anônima. Os usuários podem acessar o conteúdo do SharePoint sem validar suas credenciais. A autenticação anônima é desativada por padrão. Normalmente, utiliza a autenticação anónima quando utiliza o SharePoint Server para publicar conteúdos que não necessitam de segurança e estão disponíveis para todos os utilizadores, como um site público da Internet.
Além de ativar a autenticação anónima, também tem de configurar o acesso anónimo (permissões) em sites e recursos do site.
Observação
Sites do Serviços de Informações da Internet (IIS) criados pelo SharePoint para atenderem a aplicativos Web sempre devem ter os métodos Autenticação Anônima e Autenticação de Formulários habilitados, mesmo quando as configurações do SharePoint para eles estiverem desabilitadas. Isso é intencional e desabilitar a autenticação anônima ou de formulários diretamente nas configurações do IIS resultará em erros no site do SharePoint.
Autenticação baseada em formulários
A autenticação baseada em formulários é um sistema de gerenciamento de identidade baseada em declarações que é criado sobre a associação do ASP.NET e a autenticação de provedor de função. A autenticação baseada em formulários pode ser utilizada em relação às credenciais armazenadas num fornecedor de autenticação, tais como:
AD DS
Um banco de dados, por exemplo do SQL Server
Um armazenamento de dados do Lightweight Directory Access Protocol (LDAP) como o Novell eDirectory, Novell Directory Services (NDS) ou Sun ONE
A autenticação baseada em formulários valida o usuário com base nas credenciais que ele digita em um formulário de logon (normalmente, uma página da web). Os pedidos não autenticados são redirecionados para uma página de início de sessão, onde um utilizador tem de fornecer credenciais válidas e submeter o formulário. O sistema emite um cookie para as solicitações autenticadas que contêm uma chave, para restabelecer a identidade para as solicitações subsequentes.
Assista ao vídeo de autenticação de declarações baseada em formulários no SharePoint 2013 e no SharePoint Server 2016
Observação
Com a autenticação baseada em formulários, as credenciais da conta de usuário são enviadas como texto simples. Portanto, você não deve usar a autenticação baseada em formulários, a menos que você também esteja usando o SSL para criptografar o tráfego do site.
Para saber mais, confira Planeje a autenticação baseada em formulários.
Autenticação baseada em tokens do SAML
A autenticação baseada em tokens do SAML SharePoint Server usa o protocolo SAML 1.1 e o protocolo WS-F PRP (Perfil de solicitante passivo do WS-Federation). Isso exige a coordenação com administradores de um ambiente baseado em declarações, independente de ser o próprio ambiente interno ou um ambiente de parceiros. Se você usa os Serviços de Federação do Active Directory (AD FS) 2.0, possui um ambiente de autenticação baseada em tokens do SAML.
Um ambiente de autenticação baseada em tokens do SAML inclui um serviço de token de segurança do fornecedor de identidade (IP-STS). O IP-STS emite tokens de SAML em nome dos usuários cujas contas estão incluídas no provedor de autenticação associado. Os tokens podem incluir qualquer número de declarações sobre um usuário, como um nome e os grupos aos quais ele pertence. Um servidor do AD FS 2.0 é um exemplo de um IP-STS.
O SharePoint Server aproveita as vantagens das declarações incluídas nos tokens que um IP-STS emite para os usuários autorizados. Em ambientes de declarações, um aplicativo que aceita tokens de SAML é conhecido como um STS de parte confiável (RP-STS). Um aplicativo de parte confiável recebe o token de SAML e usa as declarações dentro dele para decidir se irá permitir o acesso do cliente ao recurso solicitado. No SharePoint Server, cada aplicativo Web que está configurado para usar um provedor do SAML é adicionado ao servidor de IP-STS como uma entrada de RP-STS separada. Um farm do SharePoint pode representar múltiplas entradas de RP-STS no IP-STS.
Assista ao vídeo de autenticação de declarações baseada em SAML no SharePoint 2013 e no SharePoint Server 2016
O conjunto de provedores de autenticação para a autenticação baseada em tokens do SAML depende do IP-STS em seu ambiente de declarações. Se utilizar o AD FS 2.0, os fornecedores de autenticação (conhecidos como arquivos de atributos para o AD FS 2.0) podem incluir:
Windows Server 2003 Active Directory e AD DS no Windows Server 2008
Todas as edições do SQL Server 2005 e SQL Server 2008
Repositórios de atributos personalizados
Para saber mais, confira Planeje a autenticação baseada em tokens do SAML.
Escolhendo tipos de autenticação para ambientes LDAP
A autenticação baseada em formulários ou em tokens do SAML pode usar ambientes LDAP. Utilize o tipo de autenticação que corresponde ao seu ambiente LDAP atual. Se ainda não tiver um ambiente LDAP, recomendamos que utilize a autenticação baseada em formulários porque é menos complexa. No entanto, se o ambiente de autenticação já der suporte ao WS-Federation 1.1 e ao SAML 1.1, recomendamos o SAML. O SharePoint Server tem um provedor LDAP incorporado.
Planeje a autenticação do Windows
O processo de planejar e implementar os métodos de autenticação do Windows é semelhante à autenticação baseada em declarações. A autenticação baseada em afirmações para uma aplicação Web não aumenta a complexidade da implementação de métodos de autenticação do Windows. Esta seção resume o planejamento para os métodos de autenticação do Windows.
NTLM e o protocolo Kerberos
O NTLM e o protocolo Kerberos são métodos integrados de autenticação do Windows, que permitem aos usuários uma autenticação simples, sem solicitar credenciais. Por exemplo:
Os usuários que acessam sites do SharePoint com o Internet Explorer usam as credenciais que o processo do Internet Explorer está executando para autenticar. Por predefinição, estas credenciais são as credenciais que o utilizador utilizou para iniciar sessão no computador.
Serviços ou aplicativos que usam os métodos integrados de autenticação do Windows para acessar os recursos do SharePoint tentam usar as credenciais do encadeamento em execução, que por padrão é a identidade do processo, para autenticar.
O NTLM é a forma mais simples de autenticação do Windows a implementar e, normalmente, não requer nenhuma configuração adicional da infraestrutura de autenticação. Selecione esta opção quando criar ou configurar a aplicação Web.
O protocolo Kerberos suporta autenticação de tíquetes. A utilização do protocolo Kerberos requer mais configuração do ambiente. Para ativar a autenticação Kerberos, os computadores cliente e servidor devem ter uma conexão confiável ao KDC do domínio. A configuração do protocolo Kerberos envolve a definição dos nomes principais do serviço (SPNs) no AD DS antes de instalar o SharePoint Server.
Os motivos pelos quais você deveria considerar a autenticação Kerberos são os seguintes:
O protocolo Kerberos é o protocolo de autenticação integrada mais forte do Windows, e suporta recursos de segurança avançados que incluem a criptografia Padrão de Criptografia Avançada (AES) e a autenticação mútua de clientes e servidores.
O protocolo Kerberos permite a delegação das credenciais do cliente.
Entre os métodos de autenticação seguros disponíveis, o Kerberos exige a menor quantidade de tráfego de rede para os controladores do domínio AD DS. O Kerberos pode reduzir a latência de página em certos cenários, ou aumentar o número de páginas que um servidor da Web de front-end pode servir em certos cenários. O Kerberos também pode reduzir a carga nos controladores de domínio.
O protocolo Kerberos é aberto e suportado por muitas plataformas e fornecedores.
Os motivos pelos quais a autenticação Kerberos pode não ser apropriada são os seguintes:
O Kerberos exige mais configuração da infraestrutura e do ambiente que outros métodos de autenticação, para funcionar corretamente. Em muitos casos, a permissão do administrador do domínio é exigida para configurar o protocolo Kerberos. A autenticação Kerberos pode ser difícil de configurar e gerenciar. A configuração incorreta do Kerberos pode impedir o sucesso na autenticação de seus sites.
A autenticação Kerberos exige a conectividade do computador cliente a um KDC e a um controlador de domínio AD DS. Em uma implantação do Windows, o KDC é um controlador de domínio AD DS. Embora esta configuração de rede seja comum numa intranet da organização, as implementações com acesso à Internet normalmente não são configuradas desta forma.
As etapas a seguir resumem a configuração da autenticação Kerberos:
Configure a autenticação Kerberos para as comunicações do SQL Server criando SPNs no AD DS para a conta de serviço do SQL Server.
Crie SPNs para os aplicativos da web que usarão a autenticação Kerberos.
Instale o farm do SharePoint Server.
Configure serviços específicos dentro do farm para usar contas específicas.
Crie os aplicativos da web que usarão a autenticação Kerberos.
Digest e Básico
Com o método de autenticação Digest, as credenciais da conta do usuário são enviadas como um sumário da mensagem MD5 para o serviço do Serviços de Informações da Internet (IIS) no servidor da web que hospeda o aplicativo ou zona da web. Com o método de autenticação Básico, elas são enviadas como texto simples. Por conseguinte, não deve utilizar o método de autenticação Básico, a menos que também esteja a utilizar o SSL para encriptar o tráfego do site.
Você pode ter que usar esses métodos de autenticação mais antigos, se o ambiente usar navegadores ou serviços da web que suportam somente a autenticação Digest ou Básica para os sites.
Diferente do NTLM, Kerberos e métodos de autenticação anônima, você configura a autenticação Digest e Básica a partir das propriedades do site que corresponde ao aplicativo ou zona da web no snap-in do Serviços de Informações da Internet (IIS).
Se estiver a utilizar a autenticação baseada em afirmações, veja:
Configurar a autenticação digest para um aplicativo Web baseado em declarações no SharePoint Server
Configurar a autenticação básica para um aplicativo web baseado em declarações no SharePoint Server
Planeje a autenticação baseada em formulários
Para utilizar a autenticação baseada em formulários para autenticar os utilizadores num sistema de gestão de identidades que não é baseado no Windows ou externo, tem de registar o fornecedor de associação e o gestor de funções no ficheiro Web.config. O SharePoint Server usa a interface do gerenciador de função padrão do ASP.NET para coletar informações do grupo sobre o usuário atual. Cada função do ASP.NET é tratada como um grupo de domínio pelo processo de autorização no SharePoint Server. Você registra os gerenciadores de função no arquivo Web.config exatamente como registra os provedores de associação para a autenticação.
Se deseja gerenciar os usuários ou funções de associação do site do Administração Central, registre o provedor da associação e o gerenciador da função no arquivo Web.config para o site do Administração Central. Registe o fornecedor de associação e o gestor de funções no ficheiro Web.config da aplicação Web que aloja o conteúdo.
Para ver as etapas detalhadas da configuração da autenticação baseada em formulários, confira Configurar autenticação baseada em formulários para o aplicativo da Web baseado em declarações no SharePoint Server
Planeje a autenticação baseada em tokens do SAML
A arquitetura para implementar os provedores baseados em tokens do SAML incluem os componentes a seguir:
Serviço do token de segurança do SharePoint Esse serviço cria os tokens do SAML usados pelo farm. O serviço é criado automaticamente e iniciado em todos os servidores em um farm de servidor. Ele é usado para a comunicação entre os farms, porque essa comunicação usa a autenticação baseada em declarações. O serviço também é usado para os métodos de autenticação implementados para aplicativos da web que usam a autenticação baseada em declarações. Estes métodos incluem a autenticação do Windows, a autenticação baseada em formulários e a autenticação baseada em tokens SAML.
Certificado de assinatura de tokens (ImportTrustCertificate) Este certificado é aquele que exporta a partir de um IP-STS e, em seguida, copia para um servidor no farm e adiciona-o à lista autoridade de raiz fidedigna do farm. Depois de utilizar este certificado para criar um SPTrustedIdentityTokenIssuer, não pode utilizá-lo para criar outro. Para usar o certificado para criar um SPTrustedIdentityTokenIssuer diferente, é necessário excluir primeiro o existente. Antes de excluir o existente, é necessário desassociá-lo de todos os aplicativos da web que o utilizam.
Declaração de identidade Esta é a declaração de um token do SAML que é o identificador exclusivo do usuário. Somente o proprietário do IP-STS sabe qual valor presente no token sempre será exclusivo de cada usuário. A declaração de identidade é criada como um mapeamento das declarações regulares durante o mapeamento de todas as declarações desejadas. A declaração que serve como a declaração de identidade é declarada quando o SPTrustedIdentityTokenIssuer é criado.
Outras afirmações Estas afirmações consistem em afirmações adicionais de um pedido SAML que descreve os utilizadores. Eles podem incluir funções e grupos do usuário, ou outros tipos de declarações como idade. Todos os mapeamentos de declaração são criados como objetos reproduzidos pelos servidores em um farm do SharePoint Server.
Território Na arquitetura de declarações do SharePoint, o URI ou URL associado a um aplicativo da web do SharePoint, configurado para usar um provedor baseado nos tokens do SAML, representa um território. Quando você cria um provedor da autenticação baseada no SAML no farm, especifica os territórios, ou URLs de aplicativo da web, que deseja que o IP-STS reconheça, um de cada vez. O primeiro território é especificado quando você cria o SPTrustedIdentityTokenIssuer. Você pode adicionar mais territórios depois de criar o SPTrustedIdentityTokenIssuer. Os territórios são especificados usando uma sintaxe semelhante à seguinte:
$realm = "urn:sharepoint:mysites". Depois de adicionar o território ao SPTrustedIdentityTokenIssuer, crie uma confiança do RP-STS com o identificador de território no servidor do IP-STS. Esse processo envolve especificar a URL do aplicativo da web.SPTrustedIdentityTokenIssuer Este é o objeto criado no farm do SharePoint que inclui os valores necessários para se comunicar com e receber os tokens do IP-STS. Quando cria o SPTrustedIdentityTokenIssuer, especifica o certificado de assinatura de tokens a utilizar, o primeiro realm, a afirmação que representa a afirmação de identidade e quaisquer outras afirmações. Você pode associar somente um certificado de assinatura por token de um STS a um SPTrustedIdentityTokenIssuer. No entanto, depois de criar o SPTrustedIdentityTokenIssuer, pode adicionar mais realms para aplicações Web adicionais. Depois de adicionar um realm ao SPTrustedIdentityTokenIssuer, você também deve adicioná-lo ao IP-STS como uma parte confiável. O objeto SPTrustedIdentityTokenIssuer é reproduzido pelos servidores no farm do SharePoint Server.
Serviço de token de segurança da parte confiável (RP-STS) No SharePoint Server, cada aplicativo Web configurado para usar um provedor do SAML é adicionado ao servidor do IP-STS como uma entrada RP-STS. Um farm do SharePoint Server pode incluir várias entradas RP-STS.
Serviço de token de segurança do fornecedor de identidade (IP-STS) Este serviço é o token seguro no ambiente de afirmações que emite tokens SAML em nome dos utilizadores incluídos no diretório de utilizador associado.
O diagrama a seguir mostra a arquitetura de declarações de token do SAML do SharePoint Server.
Arquitetura de declarações de token do SAML
O objeto SPTrustedIdentityTokenIssuer é criado com vários parâmetros, que incluem:
Uma única declaração de identidade.
Um único parâmetro SignInURL .
O parâmetro SignInURL especifica o URL para o qual redirecionar um pedido de utilizador para para autenticar para o IP-STS.
Um único parâmetro Wreply .
Alguns servidores IP-STS requerem o parâmetro Wreply , que está definido como verdadeiro ou falso. Falso é o padrão. Utilize o parâmetro Wreply apenas se for necessário pelo IP-STS.
Vários realms.
Vários mapeamentos de declarações
Para implementar a autenticação baseada em tokens SAML com o SharePoint Server, implemente os seguintes passos que requerem planeamento antecipado:
Exporte o certificado de assinatura com token do IP-STS. Copie o certificado para um servidor no farm do SharePoint Server.
Defina a declaração que será usada como o identificador exclusivo do usuário. Esta afirmação é conhecida como a afirmação de identidade. O nome principal do usuário (UPN) ou nome de email do usuário é frequentemente usado como o identificador. Coordene com o administrador do IP-STS para determinar o identificador correto, porque somente o proprietário do IP-STS conhece o valor no token que sempre será exclusivo de cada usuário. Determinar o identificador exclusivo do usuário é uma parte do processo de mapeamento da declaração. Use o Microsoft PowerShell para criar mapeamentos de declarações.
Definir mapeamentos de afirmações adicionais. Defina as afirmações adicionais do token de entrada que o farm do SharePoint Server irá utilizar. As funções do usuário são exemplos de uma declaração que pode ser usada para atribuir permissões aos recursos no farm do SharePoint Server. Todas as afirmações de um token de entrada que não tenham um mapeamento serão eliminadas.
Use o PowerShell Use para criar um novo provedor de autenticação para importar o certificado de assinatura por token. Esse processo cria o SPTrustedIdentityTokenIssuer. Durante este processo, especifique a afirmação de identidade e afirmações adicionais que mapeou. Crie e especifique um realm associado às primeiras aplicações Web do SharePoint que está a configurar para a autenticação baseada em tokens SAML. Depois de criar o SPTrustedIdentityTokenIssuer, pode criar e adicionar mais realms para aplicações Web do SharePoint adicionais. Este procedimento permite-lhe configurar várias aplicações Web para utilizar o mesmo SPTrustedIdentityTokenIssuer.
Para cada realm que você adiciona ao SPTrustedIdentityTokenIssuer, crie uma entrada de RP-STS no IP-STS. Pode criar esta entrada antes de a aplicação Web do SharePoint existir. Indiferentemente disso, é necessário planejar o URL antes de criar os aplicativos da web.
Para um aplicativo da web do SharePoint novo ou existente, configure-o para usar o provedor de autenticação recém-criado. Esse provedor é exibido como um provedor de identidade confiável no Administração Central quando você cria um aplicativo da web.
Você pode configurar vários provedores de autenticação baseada em tokens do SAML. No entanto, pode usar somente um certificado de assinatura por token de cada vez em um farm. Todos os provedores configurados são exibidos como opções no Administração Central. As afirmações de diferentes ambientes STS fidedignos não entrarão em conflito.
Se você implementar a autenticação baseada em tokens do SAML com uma empresa parceira e seu próprio ambiente inclui um IP-STS, recomendamos que você e o administrador do ambiente interno de declarações estabeleçam uma relação de confiança unidirecional, do seu IP-STS interno para o STS do parceiro. Esta abordagem não requer que adicione um fornecedor de autenticação ao farm do SharePoint Server. Ela também permite que os administradores de declarações gerenciem o ambiente de declarações inteiro.
Importante
[!IMPORTANTE] Não é mais necessário configurar o balanceamento de carga da rede para a afinidade única quando estiver usando a autenticação baseada em declarações no SharePoint Server.
Observação
[!OBSERVAçãO] Quando um aplicativo Web é configurado para usar a autenticação baseada em tokens do SAML, a classe SPTrustedClaimProvider não fornece a funcionalidade de pesquisa para o controle Seletor de Pessoas. Qualquer texto inserido nesse controle será automaticamente exibido enquanto se resolve, independente de ser um usuário, grupo ou declaração válido. Se a sua solução do SharePoint Server usar a autenticação baseada em tokens do SAML, planeje criar um provedor de declarações personalizado que implemente a pesquisa personalizada e a resolução de nome.
Para ver as etapas detalhadas de configuração da autenticação baseada em tokens em SAML usando AD FS, confira Configurar a autenticação de declarações baseada em SAML com o AD FS no SharePoint Server.
Planejando zonas para aplicativos da web
As zonas representam diferentes caminhos lógicos para obter acesso aos mesmos sites em um aplicativo da web. Cada aplicativo da web pode incluir até cinco zonas. Quando você cria um aplicativo da web, o Administração Central cria a zona com o nome padrão. Para criar zonas adicionais, estenda o aplicativo da web e selecione um dos nomes de zona restantes: intranet, extranet, Internet ou personalizado.
O seu plano para as zonas dependerá do seguinte:
- Autenticação baseada em declarações (recomendado) - Você pode implementar vários provedores de autenticação em uma única zona. Também é possível usar múltiplas zonas.
Implementando mais de um tipo de autenticação em uma única zona
Se você usara autenticação baseada em declarações e implementar mais de um método de autenticação, recomendamos implementar múltiplos métodos de autenticação na zona padrão. O resultado é a mesma URL para todos os usuários.
Quando você implementa múltiplos métodos de autenticação na mesma zona, as restrições a seguir se aplicam:
Você pode implementar apenas uma instância de autenticação baseada em formulários em uma zona.
O Administração Central permite usar um método integrado do Windows e o Básico ao mesmo tempo. Caso contrário, não pode implementar mais do que um tipo de autenticação do Windows numa zona.
Se diversos provedores de autenticação baseada em tokens do SAML forem configurados para um farm, todos aparecem como opções quando você cria um aplicativo da web com uma nova zona. Você pode configurar vários provedores do SAML na mesma zona.
O diagrama a seguir mostra vários tipos autenticação implementados na zona padrão, para um site de colaboração de parceiro.
Vários tipos autenticação implementados na zona padrão
No diagrama, usuários de diferentes repositórios de diretório usam a mesma URL para acessar o site do parceiro. A caixa pontilhada 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.
Planejamento para rastrear o conteúdo
O componente de rastreamento exige o NTLM para acessar o conteúdo. Pelo menos uma zona deve ser configurada para usar a autenticação NTLM. Se a autenticação NTLM não estiver configurada na zona predefinida, o componente de pesquisa pode utilizar uma zona diferente configurada para utilizar a autenticação NTLM.
Implemente mais de uma zona
Se você planeja implementar mais de uma zona para aplicativos da web, use as diretrizes a seguir:
Use a zona padrão para implementar suas configurações de autenticação mais seguras. Se não for possível associar um pedido a uma zona específica, são aplicadas as definições de autenticação e outras políticas de segurança da zona predefinida. A zona padrão é aquela criada quando você cria um aplicativo da web. Normalmente, as configurações de autenticação mais seguras são projetadas para o acesso do usuário final. Assim, é provável que os utilizadores finais acedam à zona predefinida.
Use o número mínimo de zonas exigidas para permitir acesso aos usuários. Cada zona é associada a um novo site e domínio do IIS para acessar o aplicativo da web. Adicione apenas novos pontos de acesso quando forem necessários.
Verifique se pelo menos uma zona está configurada para usar a autenticação NTLM para o componente de rastreamento. Não crie uma zona dedicada para o componente de índice, a menos que seja necessário.
O diagrama a seguir mostra várias zonas que são implementadas para acomodar diferentes tipos de autenticação para um site de colaboração de parceiros.
Uma zona por tipo de autenticação
No diagrama, a zona padrão é usada pelos funcionários remotos. Cada zona tem uma URL diferente associada. Os funcionários utilizam uma zona diferente consoante estejam a trabalhar no escritório ou a trabalhar remotamente.