Configurando uma Confiança oAuth Entre Farms no SharePoint 2013

Artigo original publicado segunda-feira, 23 de julho de 2012

Uma coisa sobre a qual você pode acabar ouvindo falar muito no SharePoint 2013, e sobre a qual eu posso acabar escrevendo muito, é oAuth. No SharePoint 2013, oAuth é usado para estabalecer uma confiança entre dois aplicativos para o propósito de estabelecer a identidade de um principal (usuário ou aplicativo). No SharePoint você usará confianças oAuth entre o SharePoint e coisas como o Exchange e o Lync, com ACS ou desenvolvedores de aplicativos individuais que estão usando o novo modelo de aplicativo de nuvem, ou até mesmo entre dois farms do SharePoint diferentes para coisas como o recurso de índice remoto do SharePoint na Pesquisa.

O que o oAuth NÃO faz é se tornar um provedor de autenticação para as pessoas; você ainda usará seu New-SPTrustedIdentityTokenIssuer para criar essas confianças para seus provedores de identidade. Para confianças oAuth nós temos um novo cmdlet cujo nome é muito parecido, chamado New-SPTrustedSecurityTokenIssuer. Quando estabelecemos este tipo de confiança com um emissor de token de segurança nos a chamamos de uma confiança S2S, o que significa “servidor para servidor”. Lembre-se deste acrônimo pois você começará a vê-lo bastante no SharePoint 2013. Nesta publicação falarei sobre algumas das particularidades necessárias para criar essa confiança.

Primeiro, vale a pena apontar que muitos recursos que exigem uma confiança S2S estabelecerão essa confiança eles mesmos. Eles podem fazer isso via ativação de recurso, ou equipes de recurso podem fornecer a você um cmdlet ou script do PowerShell para ser executado que cria essa confiança como parte da ativação do recurso. Porém, haverão momentos que você mesmo precisará fazer isso, e é disso que trata esse blog.

Uma das coisas que você precisará resolver primeiro é se você vai usar SSL ou não. A realidade é que, na maioria dos casos no SharePoint 2013, você provavelmente deve usar SSL. O motivo de eu dizer isso é que existem muitos cenários que usam oAuth no SharePoint 2013, e quando você tem um destes você está passando um cookie com um token de acesso. Este token de acesso é como uma chave que abre a porta para os dados. O token de acesso é assinado por um certificado, portanto não pode ser imitado por alguém criando seu próprio token de acesso, mas você não quer que ele vá passando por aí em texto limpo pois, em teoria, alguém poderia pegar este cookie e tocá-lo novamente por toda a duração da vida útil do cookie. SSL protege você desse ataque de replay de cookie, do mesmo modo que você usaria SSL com um site de autorização baseada em formulário pelo mesmo motivo. Tendo dito isso, ainda existem motivos para você poder querer executar seus sites via HTTP – você está em um ambiente de teste, você está construindo um ambiente de desenvolvimento, você está executando tudo em uma rede interna e não acha que é arriscado, etc. Não estou aqui para julgar – apenas para explicar. 

PASSO 1: Configurar o STS

Existem algumas definições na configuração do serviço de token de segurança STS) do SharePoint que você pode querer ajustar caso não esteja usando SSL. Você pode obter todas as definições de configuração do STS com este cmdlet: Get-SPSecurityTokenServiceConfig. Existem duas maneiras de estabelecer uma confiança – uma é com um certificado, e a outra é usando um ponto de extremidade de metadados do oAuth novo que todos os farms do SharePoint possuem. Usar o ponto de extremidade de metadados é a maneira mais fácil, mas caso esse ponto de extremidade não seja seguro com SSL, então você precisará configurar a propriedade AllowMetadataOverHttp do STS do SharePoint para verdadeiro. Caso você não vá executar seus aplicativos web sobre SSL, então você precisará configurar a propriedade AllowOAuthOverHttp também como verdadeiro. Aqui vai um pequeno PowerShell que demonstra como definir estas propriedades:

$c = Get-SPSecurityTokenServiceConfig

$c.AllowMetadataOverHttp = $true

$c.AllowOAuthOverHttp= $true

$c.Update()

PASSO 2: Criar a confiança

Uma vez que o STS esteja configurado conforme o necessário, nós podemos ver como estabelecer a confiança de um farm para outro. Como disse acima, todos os farms do SharePoint possuem um ponto de extremidade de metadados agora, que é usado para fornecer informações e o certificado de assinatura do token de acesso. Este ponto de extremidade de metadados está em /_layouts/15/metadata/json/1. Caso você tente navegar até este local em um navegador, você verá uma solicitação para salvar, o que você pode fazer para examiná-lo. O que você encontrará se você o abrir no bloco de notas é apenas uma carga JSON. Ela inclui o identificador de nome do STS (que é chamado de "emissor”), junto com uma versão serializada do certificado de assinatura do token (que é descrita como o "valor" para a chave “x509certificate”). Se você procurar um pouco mais nos dados, você verá que o emissor é, na verdade, servicename + “@” + realm values. Também corresponde à propriedade NameIdentifier no STS; essas informações são importantes por motivos que explicarei logo.

Digamos, neste exemplo, que o FARM_B precisa confiar em chamadas feitas pelo FARM_A, pois o FARM_A irá usar o FARM_B como um índice remoto do SharePoint. Além disso, digamos que o FARM_A possui um aplicativo web em https://FARM_A. Para criar a confiança, precisaríamos executar o cmdlet New-SPTrustedSecurityTokenIssuer em um servidor no FARM_B desse modo (explicarei porque estou usando “$i = “ mais à frente):

$i = New-SPTrustedSecurityTokenIssuer -Name FARM_A -Description "FARM_A description" -IsTrustBroker:$false -MetadataEndPoint "https://FARM_A/_layouts/15/metadata/json/1"

Agora, digamos que você está configurando uma confiança com um farm apenas de serviços. Você não quer criar um aplicativo web, conjunto de sites e certificado SSL apenas para poder criar uma confiança a partir dele. Então, nós temos um segundo método que você pode usar para estabelecer a confiança usando o novo cmdlet New-SPTrustedSecurityTokenIssuer. No segundo formulário você pode apenas fornecer o nome do certificado de assinatura de token e o identificador de nome. Você obtém o certificado de assinatura de token do mesmo modo que fazia no SharePoint 2010 – indo para um servidor no farm, executando o MMC, adicionando o snap-in Certificados para o Computador Local, procurando no nó SharePoint…Certificados, e o primeiro certificado na lista será aquele que você quer – apenas salve-o no drive local sem a chave privada como um arquivo .cer. Você precisa do certificado e do atributo NameIdentifier do STS que eu estava descrevendo acima para estabelecer a confiança. O cmdlet neste caso se parece com isso (ele presume que você copiou o certificado STS para um arquivo chamado C:\sts.cer em um servidor no FARM_B):

$i = New-SPTrustedSecurityTokenIssuer -name FARM_A -Certificate "C:\sts.cer" -RegisteredIssuerName "00000003-0000-0ff1-ce00-000000000000@72da1552-085a-49de-9ecb-73ba7eca8fef " -Description "FARM_A description" -IsTrustBroker:$false

PASSO 3: Confiar no Certificado de Assinatura de Token

Do mesmo modo que você faz com um SPTrustedIdentityTokenIssuer, você precisa adicionar a confiança usada para assinar tokens do oAuth à lista de autoridades confiáveis de raiz no SharePoint. Novamente, você tem duas opções para fazer isso: caso crie sua confiança através do ponto de extremidade de metadados, você pode estabelecer a confiança assim:

New-SPTrustedRootAuthority -Name FARM_A -MetadataEndPoint https://FARM_A/_layouts/15/metadata/json/1/rootcertificate

Do contrário, você pode criar e adicioná-la à autoridade confiável de raiz do mesmo modo que fazia no SharePoint 2010:

$root = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("C:\sts.cer")

New-SPTrustedRootAuthority -Name "Token Signing Root CA Certificate" -Certificate $root

De uma perspectiva de confiança, você já terminou nesse ponto – sua confiança está estabelecida e você pode agora criar novos principais de aplicativos baseados nela. Como você a usará baseia-se no aplicativo em si; no caso de um índice remoto do SharePoint eu vou em frente e concluirei o cenário, para que fique completo.

PASSO 4: Criar um Principal de Aplicativo (exemplo apenas para índice remoto do SharePoint):

Existem duas etapas neste processo – obter um principal de aplicativo e conceder direitos a ele. Lembre-se do nosso cenário de que o FARM_B precisa confiar em chamadas do FARM_A pois ele receberá consultas para o índice remoto do SharePoint. Então, para o meu principal de aplicativo, eu preciso obter uma referência ao aplicativo web no FARM_B que o FARM_A irá usar. Uma vez que eu tenha essa referência eu posso conceder direitos para o FARM_A o use.

Para obter uma referência ao principal de aplicativo você usa o cmdlet assim:

$p = Get-SPAppPrincipal -Site https://FARM_B -NameIdentifier $i.NameId

IMPORTANTE: Existe uma coisa importante para se notar aqui, que eu acredito que será especialmente comum durante a versão beta do SharePoint 2013. Você pode receber erros estranhos no PowerShell ao tentar obter o SPAppPrincipal. O que eu descobri é que, se a memória disponível no seu servidor cair para menos de 5%, todas as chamadas WCF falharão. Já que este cmdlet do PowerShell chama um ponto de extremidade de aplicativo de serviço, que é hospedado como um WCF, o cmdlet Get-SPAppPrincipal falha quando a memória está baixa. Você pode verificar no Visualizador de Eventos do Windows no Log de Aplicativo para ver se essa é a causa do seu problema. Isso aconteceu várias vezes comigo até agora portanto é possível que outros verão isso também.

Observe que, como eu descrevi antes nesta publicação, eu finalmente posso usar a variável $i para obter o NameIdentifier do STS no FARM_A. Agora que eu tenho uma referência ao principal do aplicativo para o aplicativo web do FARM_B, eu posso conceder direitos para ele assim:

Set-SPAppPrincipalPermission -Site https://FARM_B -AppPrincipal $p -Scope SiteSubscription -Right FullControl

Aí está – essas são suas opções e metodologias para criar uma confiança oAuth entre dois farms do SharePoint. Eu continuarei a explorar o oAuth e os vários usos e problemas sobre os quais temos de estar cientes com o tempo neste blog.

Esta é uma publicação localizada. Encontre o artigo original em Setting Up an oAuth Trust Between Farms in SharePoint 2013