Criação de suplementos do SharePoint que usem autorização de alto nível de confiança

  • Artigo

Um suplemento de alta confiança é um suplemento do SharePoint, hospedado pelo provedor, que está instalado localmente no farm do SharePoint. Não pode ser instalado no Microsoft SharePoint Online ou comercializado pela Office Store. Um suplemento de alta confiança usa um certificado, em lugar de um token de contexto, para estabelecer a confiança.

Observação

Este tópico ajuda você a compreender o sistema de alta confiança para suplementos do SharePoint. Para obter informações práticas sobre como criar e implantar suplementos de alta confiança, consulte os seguintes tópicos:

No SharePoint, o serviço de token de segurança (STS) fornece tokens de acesso para a autenticação de servidor-a-servidor. O STS permite que tokens de acesso temporário acessem outros aplicativos de serviços, como o Exchange, Lync e suplementos do SharePoint. Um administrador de farm estabelece confiança entre o SharePoint e o outro aplicativo, ou suplemento, usando cmdlets do Windows PowerShell e um certificado. Cada certificado usado deve ser confiável pelo SharePoint usando o New-SPTrustedRootAuthority cmdlet. Também, cada certificado deve ser registrado no SharePoint como um emissor de tokens, usando o New-SPTrustedSecurityTokenIssuer cmdlet.

Observação

O STS não é usado para a autenticação do usuário. Por isso você não verá o STS listado na página de entrada do usuário, na seção de Provedor de Autenticação da Administração Central, ou no Seletor de Pessoas no Share Point.

Dois tipos de emissores de token

O aplicativo remoto de um suplemento de alta confiança do SharePoint está associado a um certificado digital. (Para saber mais sobre como fazer isso, consulte os dois tópicos vinculados anteriormente.) O certificado é usado pelo aplicativo web remoto para assinar os tokens de acesso que ele inclui em todas as suas solicitações para o SharePoint. O aplicativo web assina o token com a chave privada do certificado e o SharePoint o valida com a chave pública do certificado. O certificado deve ser registrado como um emissor de token confiável antes que o SharePoint confie nos tokens que ele emite.

Existem dois tipos de emissores de tokens, alguns somente podem emitir tokens para um determinado suplemento do SharePoint; outros, chamados de agentes de confiabilidade, podem emitir tokens para suplementos de SharePoint múltiplos.

Na prática, os administradores de farm do SharePoint determinam que tipo de emissor de token é criado através das chaves e os valores de parâmetros que eles usam com o New-SPTrustedSecurityTokenIssuer cmdlet. Para criar um emissor de token, que seja um agente de confiabilidade, adicione a -IsTrustBrokerchave na linha de comando e use um valor único, diferente do suplemento de ID do cliente, para o-Name parâmetro. A seguir veja um exemplo editado.

New-SPTrustedSecurityTokenIssuer -IsTrustBroker -RegisteredIssuerName "<full_token_issuer_name> " --other parameters omitted--

Para criar um emissor de token, que não seja um agente, a -IsTrustBroker chave não é usada. Há mais uma diferença. O valor do -RegisteredIssuerName parâmetro é sempre na forma de dois GUIDs separados pelo caractere "@"; GUID@GUID. O GUID no lado direito é sempre a ID do domínio de autenticação do farm do SharePoint (ou a assinatura do site). O GUID no lado esquerdo sempre é uma ID específica para o emissor do token.

O GUID é aleatório quando um agente de confiabilidade emissor de token é criado. Mas quando emissor do token, sem agente, está sendo criado, o emissor GUID específico deve ser o mesmo GUID usado como a ID do cliente do suplemento do SharePoint. O parâmetro fornece um nome para o emissor. Ele também informa o Share Point qual é o suplemento do Share Point único para o qual esse certificado pode emitir tokens. A seguir vemos um exemplo parcial:

$fullIssuerIdentifier = "<client_ID_of_SP_app> " + "@" + "<realm_GUID> "
New-SPTrustedSecurityTokenIssuer -RegisteredIssuerName $fullIssuerIdentifier --other parameters omitted--

Normalmente, o New-SPTrustedSecurityTokenIssuer cmdlet é usado em um script que realiza outras tarefas para configurar o SharePoint para suplementos de alta confiança. Para saber mais sobre esses scripts e exemplos completos do New-SPTrustedSecurityTokenIssuer cmdlet, consulte Scripts de configuração de alta confiança para o SharePoint.

Decidindo entre o uso de um ou vários certificados para suplementos do SharePoint de alta confiança

O SharePoint e os administradores de rede podem escolher entre duas estratégias básicas quando obtém e gerenciam certificados para uso por suplementos de alta confiança do SharePoint:

  • Usar o mesmo certificado para vários suplementos do SharePoint.

  • Usar um certificado separado para cada suplemento do SharePoint.

Esta seção discute os prós e contras de cada estratégia.

A vantagem de usar o mesmo certificado para suplementos múltiplos do SharePoint é que o administrador tem menos certificados para confiar e gerenciar. A desvantagem dessa abordagem é que, quando você quiser quebrar a confiabilidade com um determinado suplemento do SharePoint, a única opção para o administrador é remover o certificado, como emissor de token ou como autoridade raiz. Mas remover o certificado também quebra a confiabilidade com todos os outros suplementos do SharePoint que usam o mesmo certificado, o que faz com que todos eles deixem de funcionar.

Para que os suplementos do SharePoint ainda confiáveis funcionem novamente, o administrador precisaria criar um New-SPTrustedSecurityTokenIssuer objeto usando um novo certificado e incluir o -IsTrustBroker sinalizador. O novo certificado precisará ser registrado com cada servidor que hospeda qualquer um dos suplementos confiáveis e cada um desses suplementos precisará estar vinculado ao novo certificado.

A vantagem de usar um certificado por suplemento é que isso facilita a quebra de confiabilidade com um suplemento específico, porque os certificados que são usados pelos suplementos ainda confiáveis não são afetados quando o administrador quebra a confiabilidade com o certificado de um suplemento. A desvantagem dessa estratégia é que um administrador tem que adquirir mais certificados e o SharePoint deverá ser configurado para usar cada um deles; isso pode ser feito com um script reutilizável conforme mostrado em Scripts de configuração de alta confiabilidade para o SharePoint .

Certificados são autoridades raiz no SharePoint

Conforme mencionado anteriormente neste artigo, os administradores de farm do SharePoint precisam tornar o certificado do aplicativo de web remoto, no suplemento de alta confiança, numa autoridade raiz confiável no SharePoint, bem como num emissor de token confiável. Na verdade, quando há uma hierarquia de autoridades emitindo certificados, por trás do certificado do aplicativo da web, todos os certificados na cadeia devem ser adicionados à lista do SharePoint de autoridades raiz confiáveis.

Cada certificado na cadeia é adicionado à lista de autoridades raiz confiáveis do SharePoint com uma chamada do New-SPTrustedRootAuthority cmdlet. Por exemplo, suponhamos que o certificado do aplicativo da web é um certificado de domínio emitido por uma autoridade de certificação de domínio na rede local e, vamos supor, que o certificado, por sua vez, foi emitido por uma autoridade de certificação autônoma de nível superior na rede local. Nesse cenário, os certificados da AC de nível superior, a AC intermediária e o aplicativo web têm que ser todos adicionados à lista de autoridades raiz confiáveis do SharePoint. O seguinte código do Windows PowerShell faria isso.

$rootCA = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("<path_to_top-level_CA's_cer_file>")
New-SPTrustedRootAuthority -Name "<name_of_certificate>" -Certificate $rootCA

$intermediateCA = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("path_to_intermediate_CA's_cer_file")
New-SPTrustedRootAuthority -Name "<name_of_certificate>" -Certificate $intermediateCA

$certificate = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("path_to_web_application's_cer_file") 
New-SPTrustedRootAuthority -Name "<name_of_certificate>" -Certificate $certificate

A raiz e os certificados intermediários devem ser adicionados somente uma vez em um farm do SharePoint. Normalmente, o certificado do aplicativo web é adicionado em um script separado que também faz outra configuração, como a chamada para New-SPTrustedSecurityTokenIssuer. Para obter exemplos, confira Scripts de configuração de alta confiabilidade para o SharePoint.

Se o certificado do aplicativo Web é auto assinado, como pode ser o caso quando o suplemento está sendo desenvolvido e depurado, não há uma cadeia de certificados e somente o certificado do aplicativo da web precisa ser adicionado à lista de autoridades raiz.

Para saber mais, confira a postagem do blog Raiz de Cadeia de Certificados Não Confiáveis Erro na Autenticação de Declarações. Role até depois da seção sobre como exportar o certificado dos Serviços de Federação do Active Directory(AD FS), supondo que você tenha criado seu certificado para os suplementos de alta confiança por outros meios, usando, por exemplo, um certificado comercial emitido por uma Autoridade de Certificação, um certificado auto assinado ou um certificado emitido por um domínio.

O Aplicativo da web precisa saber que ele é um emissor de token

O componente do aplicativo da web remoto do suplemento do SharePoint está associado ao seu certificado no IIS. Para as finalidades tradicionais dos certificados é suficiente identificar o aplicativo da web e codificar as solicitações e respostas HTTP com segurança.

No entanto, em um suplemento de alta confiança do SharePoint, o certificado tem a tarefa adicional de ser o emissor oficial de tokens de acesso que o aplicativo da web envia ao SharePoint. Para isso, o aplicativo web precisa saber a ID do emissor do certificado que é usado ao registrar o certificado como um emissor de token com o SharePoint. O aplicativo da web recebe essa ID da seção appSettings do arquivo web.config, onde existe uma chave chamada IssuerId.

Instruções para que o desenvolvedor de suplemento defina esse valor e como o certificado está associado ao aplicativo web no IIS, estão contidos no Empacotar e publicar suplementos de alta confiança.

Observe que, se o cliente está usando a estratégia de ter um certificado separado para cada suplemento de alta confiança do SharePoint, o valor do ClientId também é usado como o valor de IssuerId. Isso não é o caso, quando vários suplementos compartilham o mesmo certificado, porque cada suplemento do SharePoint deve ter sua própria ID exclusiva do cliente, mas a ID emissora é o identificador para um objeto SPTrustedSecurityTokenIssuer.

A seguir temos um exemplo de uma seção appSettings para um suplemento de alta confiança do SharePoint. Neste exemplo, um certificado é compartilhado por vários suplementos, portanto o IssuerId não é igual ao ClientId. Observe que não há uma chave ClientSecret em um suplemento de alta confiança do SharePoint.

<appSettings>
  <add key="ClientId" value="6569a7e8-3670-4669-91ae-ec6819ab461" />
  <add key="ClientSigningCertificatePath" value="C:\MyCerts\HighTrustCert.pfx" />
  <add key="ClientSigningCertificatePassword" value="3VeryComplexPa$$word82" />
  <add key="IssuerId" value="e9134021-0180-4b05-9e7e-0a9e5a524965" />
</appSettings>

Observação

O exemplo anterior pressupõe que o certificado fica armazenado no sistema de arquivos. Isso é aceitável para desenvolvimento e depuração. Em uma produção de suplemento de alta confiança do SharePoint, o certificado normalmente é armazenado no Repositório de certificados do Windows, e o ClientSigningCertificatePath e as chaves ClientSigningCertificatePassword normalmente são substituídas por uma chave ClientSigningCertificateSerialNumber.

Responsabilidades da equipe de TI no sistema de alta confiança

Os desenvolvedores tem que entender os requisitos de segurança de aplicativos descritos acima, mas os profissionais de TI implementarão a infraestrutura necessária para dar suporte a ela. Profissionais de TI devem planejar para os seguintes requisitos operacionais:

  • Criar ou adquirir um ou mais certificados que serão usados para Suplementos do SharePoint confiáveis.

  • Garantir que os certificados estão armazenados com segurança nos servidores de aplicativo da web. Quando o sistema operacional Windows está sendo usado, isso significa armazenar os certificados no Repositório de Certificados do Windows.

  • Gerenciar a distribuição desses certificados para os desenvolvedores que estão criando suplementos do SharePoint.

  • Acompanhar onde cada certificado é distribuído para os dois suplementos que os estão usando e os desenvolvedores que receberam uma cópia. Se um certificado tiver que ser revogado, a equipe de TI deve trabalhar com cada desenvolvedor para fazer com que ocorra uma transição gerenciada para um novo certificado.

Confira também