Plano para métodos de autenticação do usuário no SharePoint Server
APLICA-SE A:
2013 2019 Subscription Edition 
SharePoint no Microsoft 365
Observação
Os métodos de autenticação de usuário mencionados aqui se aplicam a SharePoint Server 2013, SharePoint Server 2016, SharePoint Server 2019 e Edição de Assinatura do SharePoint Server.
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
Em Edição de Assinatura do SharePoint Server, agora oferecemos suporte à autenticação OIDC 1.0. Para obter mais informações sobre como trabalhar com esse novo tipo de autenticação, consulte Autenticação 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 usuário. 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.
Seu planejamento para tipos e métodos de autenticação de usuário 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 de modo clássico do Windows não tem mais suporte no SharePoint Server 2016, SharePoint Server 2019 e Edição de Assinatura do SharePoint Server.
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 essa funcionalidade funcione bem para ambientes windows, ela não é dimensionada para provedores de autenticação de terceiros e ambientes multi fornecedores que dão suporte a modelos de computação baseados em Internet, parceiros ou nuvem.
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 declaração representa um item específico de dados sobre usuários, como seus nomes, associações de grupo 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. Essas alterações resultam em um token de segurança (também conhecido como token de declarações) para cada usuário. 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 desenvolvedores e administradores do SharePoint podem aumentar os tokens de usuário com mais declarações. Por exemplo, contas de usuário do Windows e contas baseadas em formulários podem ser aumentadas com declarações extras que são usadas pelo SharePoint Server.
Você não precisa ser um arquiteto de declarações para usar a autenticação baseada em declaraçõ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 usuário que são contas tradicionais do Windows e contas de declaraçõ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. Você não pode migrar um aplicativo Web que usa autenticação baseada em declarações para usar 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 dá suporte a vários métodos de autenticação e provedores 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. autenticação do Windows método, que é usado por ambas as autenticações baseadas em declarações, incluem:
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, você usa a autenticação anônima quando usa o SharePoint Server para publicar conteúdo que não requer segurança e está disponível para todos os usuários, como um site público da Internet.
Além de habilitar a autenticação anônima, você também deve 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 usada em credenciais armazenadas em um provedor de autenticação, 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). Solicitações não autenticadas são redirecionadas para uma página de entrada, na qual um usuário deve fornecer credenciais válidas e enviar 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 você usar o AD FS 2.0, os provedores de autenticação (conhecidos como repositórios de atributos do AD FS 2.0) poderão 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. Use o tipo de autenticação que corresponde ao ambiente LDAP atual. Se você ainda não tiver um ambiente LDAP, recomendamos que você use a autenticação baseada em formulários porque ela é 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 declarações para um aplicativo Web não aumenta a complexidade de implementar métodos 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 padrão, essas credenciais são as credenciais usadas pelo usuário para entrar 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 para implementar e normalmente não requer nenhuma configuração extra da infraestrutura de autenticação. Selecione essa opção ao criar ou configurar o aplicativo Web.
O protocolo Kerberos suporta autenticação de tíquetes. O uso 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 essa configuração de rede seja comum em uma intranet da organização, as implantações voltadas para a Internet normalmente não são configuradas dessa maneira.
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. Portanto, você não deve usar o método de autenticação básica, a menos que também esteja usando o SSL para criptografar 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 você estiver usando a autenticação baseada em declarações, consulte:
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 usar a autenticação baseada em formulários para autenticar usuários em um sistema de gerenciamento de identidade que não se baseia no Windows ou que seja externo, você deve registrar o provedor de associação e o gerenciador de funções no arquivo 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. Registre o provedor de associação e o gerenciador de funções no arquivo Web.config para o aplicativo Web que hospeda 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. Esses métodos incluem autenticação do Windows, autenticação baseada em formulários e autenticação baseada em token SAML.
Certificado de assinatura de token (ImportTrustCertificate) Esse certificado é aquele que você exporta de um IP-STS e, em seguida, copia para um servidor no farm e o adiciona à lista autoridade raiz confiável do farm. Depois de usar esse certificado para criar um SPTrustedIdentityTokenIssuer, você não poderá usá-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 declarações Essas declarações consistem em declarações extras de um tíquete SAML que descreve os usuários. 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 você cria o SPTrustedIdentityTokenIssuer, especifica qual certificado de assinatura de token usar, o primeiro reino, a declaração que representa a declaração de identidade e quaisquer outras declarações. Você pode associar somente um certificado de assinatura por token de um STS a um SPTrustedIdentityTokenIssuer. No entanto, depois de criar o SPTrustedIdentityTokenIssuer, você pode adicionar mais reinos para aplicativos Web extras. 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 provedor de identidade (IP-STS) Esse serviço é o token seguro no ambiente de declarações que emite tokens SAML em nome dos usuários incluídos no diretório de usuário 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 a URL para redirecionar uma solicitação de usuário para autenticar-se no IP-STS.
Um único parâmetro Wreply .
Alguns servidores IP-STS exigem o parâmetro Wreply , que é definido como true ou false. Falso é o padrão. Use o parâmetro Wreply somente se for necessário pelo IP-STS.
Vários realms.
Vários mapeamentos de declarações
Para implementar a autenticação baseada em token SAML com o SharePoint Server, implemente as seguintes etapas que exigem planejamento com antecedência:
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. Essa declaração é conhecida como a declaraçã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.
Defina mapeamentos de declarações extras. Defina as declarações extras do token de entrada que o farm do SharePoint Server usará. 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 declarações de um token de entrada que não têm um mapeamento serão descartadas.
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 esse processo, você especifica a declaração de identidade e as declarações extras que mapeou. Crie e especifique um reino associado aos primeiros aplicativos Web do SharePoint que você está configurando para autenticação baseada em token SAML. Depois de criar o SPTrustedIdentityTokenIssuer, você pode criar e adicionar mais reinos para aplicativos Web extras do SharePoint. Esse procedimento permite configurar vários aplicativos Web para usar o mesmo SPTrustedIdentityTokenIssuer.
Para cada realm que você adiciona ao SPTrustedIdentityTokenIssuer, crie uma entrada de RP-STS no IP-STS. Você pode criar essa entrada antes que o aplicativo Web do SharePoint exista. 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 declarações de diferentes ambientes de STS confiáveis 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. Essa abordagem não exige que você adicione um provedor 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, você não pode implementar mais de um tipo de autenticação do Windows em uma 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 padrão, o componente de rastreamento poderá usar uma zona diferente configurada para usar 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 uma solicitação não puder ser associada a uma zona específica, as configurações de autenticação e outras políticas de segurança da zona padrão serão aplicadas. 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. Portanto, é provável que os usuários finais acessem a zona padrão.
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 eles 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 usam uma zona diferente dependendo se estão trabalhando no escritório ou trabalhando remotamente.