通过

Mais dicas de solução de problemas para aplicativos de alta confiança no SharePoint 2013

  • 项目

Artigo original publicado na sexta-feira, 2 de novembro de 2012

Olá, sou um desenvolvedor de aplicativos. Gosto de desenvolver, mas, sinceramente, poderei acabar ficando rouco de tanto gritar com meu computador caso tenha que rastrear mais um problema "O emissor do token não é confiável" com meus novos aplicativos do SharePoint. Para tentar ajudá-lo a poupar sua voz (e sua sanidade), darei início aqui a uma lista de coisas que procuro quando me deparo com esse problema. Conforme eu descobrir modos novos e estimulantes de invocar esse erro e solucioná-lo, atualizarei o post aqui e colocarei um aviso de "ATUALIZADO!" abaixo.

É importante lembrar que, quando eu digo "aplicativo de alta confiança", isso significa que você NÃO está usando ACS como agente de confiança para o aplicativo do SharePoint; em vez disso, você está criando o token OAuth e assinando-o com seu próprio certificado. Sei que esse processo está todo documentado em algum lugar por aí, então não tentarei descrevê-lo novamente. Partirei do pressuposto de que você o leu, tentou realizá-lo e está pronto para mostrar aquele dedo ao seu monitor. Então, dito isso, seguem alguns modos pelos quais observei esse erro ocorrer:

  1. Adição à lista SPTrustedRootAuthority - quando você usa um certificado para assinar seus tokens OAuth, é necessário criar New-SPTrustedRootAuthority. Assim como New-SPTrustedIdentityTokenIssuer no SharePoint 2010, você deve adicionar o certificado de assinatura do token e todos os certificados na cadeia à lista de autoridades de confiança do SharePoint. Para esse processo, você pode seguir as mesmas etapas descritas neste post: https://blogs.technet.com/b/speschka/archive/2010/02/13/root-of-certificate-chain-not-trusted-error-with-claims-authentication.aspx. Apenas ignore a parte sobre exportar o certificado do ADFS. Estou supondo que você tenha criado o certificado para os aplicativos de alta confiança usando outros meios (CA de raiz pública como GoDaddy, VeriSign, etc., certificado autoassinado ou certificado assinado por domínio).
  2. ID do cliente com todos os caracteres maiúsculos - conforme descrito em outro post, certifique-se de NÃO usar letras maiúsculas ao vincular a ID do cliente ao arquivo AppManifest.xml ou ao web.config do aplicativo Web, caso esteja criando uma solução auto-hospedada. Para obter mais detalhes, consulte: https://blogs.technet.com/b/speschka/archive/2012/07/28/an-important-tip-about-client-id-values-for-s2s-apps-in-sharepoint-2013.aspx.
  3. Emissor do token não configurado como agente de confiança - também descrevi este problema em outro post. https://blogs.technet.com/b/speschka/archive/2012/09/27/another-apps-for-sharepoint-tip-with-the-error-quot-the-issuer-of-the-token-is-not-a-trusted-issuer-quot.aspx. A essência disso é garantir que você inclua o sinalizador -IsTrustBroker ao criar New-SPTrustedSecurityTokenIssuer.
  4. ATUALIZADO!: Chave IssuerId ausente em web.config - Para usar o recurso de agente de confiança dos aplicativos no SharePoint 2013, seu aplicativo deve saber qual é o IssuerId do agente de confiança quando cria o token JWT que envia ao SharePoint. Para saber isso, ele procura uma propriedade chamada IssuerId em web.config. No web.config do aplicativo, ela está no mesmo lugar de ClientId, ClientSecret, etc., e é assim: <add key="IssuerId" value="e9134021-0180-4b05-9e7e-0a9e5a524965"/>.
  5. ATUALIZADO!: Usando RTM Preview das Ferramentas do Office para Visual Studio - na verdade, há um pequeno problema nos bits do RTM Preview, corrigido no Preview 2. O código que envia o token de autorização ao SharePoint não procura o elemento IssuerId em web.config. Em vez disso, ele envia um valor diferente. O valor enviado e o motivo não são importantes. O fator REALMENTE importante é que, para contornar o problema com essa versão das ferramentas, você sempre deve usar o valor IssuerId para SPTrustedSecurityTokenIssuer na chave ClientId em web.config. Quando você obtiver os bits do Preview 2, instale-os imediatamente e altere ClientId para uma GUID exclusiva criada e registrada por você (com Register-SPAppPrincipal, conforme explicado a seguir). Não convém que todos os ClientIds sejam iguais, porque ele identifica quais aplicativos assinaram o token OAuth e é usado na interface do usuário do SharePoint. Caso você venha a precisar executar procedimentos de solução de problemas ou auditoria, será um problema se todos os aplicativos usarem o mesmo valor.

Há também um problema relacionado que merece menção: suponha que você "ache" que solucionou o erro, mas obtém um erro de Acesso Negado ao tentar recuperar conteúdo do site do SharePoint em seu aplicativo auto-hospedado. Isso pode significar que:

  1. O valor de ClientId no arquivo AppManifest.xml de seu aplicativo do SharePoint não corresponde ao valor de ClientId em web.config do aplicativo auto-hospedado. Estamos aprimorando as ferramentas do Visual Studio de modo a aliviar esse problema daqui para frente.

Agora, boa pergunta é: como rastrear elementos como esse quando quando algo do gênero ocorrer? Bem, se fosse fácil, eu não estaria rouco nem mostrando aquele dedo para o meu monitor. Porém, veja as melhores fontes de dados que encontrei até agora. Elas podem ser usadas quando esse problema ocorrer. Mais uma vez, à medida que encontrar coisas novas, eu as adicionarei à lista:

  1. Logs ULS - favorito em caráter permanente, principalmente no fim do ano. Gosto de abrir os logs ULS e simplesmente admirar o grande volume de dados. Certo, isso foi sarcasmo. Mas algo que você realmente pode fazer é acessar Administração Central, Monitoramento, Configurar log de diagnóstico. Expanda a categoria SharePoint Foundation e selecione os itens a seguir: Autenticação do Aplicativo, Autorização de Autenticação e Autenticação de Declarações. Defina o nível de log e rastreamento como Detalhado e salve as alterações. Em seguida, tente iniciar o aplicativo novamente. Selecione uma das muitas ferramentas de visualização de logs ULS para ver a solicitação sendo recebida e processada. É um bom modo de conseguir dicas sobre os problemas de autenticação do aplicativo.
  2. Fiddler - outro recurso cheio de admiradores, o Fiddler também é muito útil nessas situações. O que você verá com mais frequência é um erro 401, "não autorizado" (como sempre, o problema subjacente é "O emissor do token não é confiável"). Se você observar o último quadro na solicitação e clicar na guia Cabeçalhos do quadro Resposta, verá um cookie WWW-Authenticate parecido com isto: Bearer realm="8a96481b-6c65-4e78-b2ef-a446adb79b59",client_id="00000003-0000-0ff1-ce00-000000000000",trusted_issuers="<e9134021-0180-4b05-9e7e-0a9e5a524965@8a96481b-6c65-4e78-b2ef-a446adb79b59,00000003-0000-0ff1-ce00-000000000000@8a96481b-6c65-4e78-b2ef-a446adb79b59>" Então, o que podemos tirar disso? Bom, ao olhar esse cookie, sei que ele espera que o valor de ClientId seja e9134021-0180-4b05-9e7e-0a9e5a524965 e que meu realm seja 8a96481b-6c65-4e78-b2ef-a446adb79b59. O valor de ClientId é fácil de verificar: basta olhar no arquivo AppManifest.xml e em web.config do aplicativo auto-hospedado. É extremamente improvável que seu realm esteja errado, mas sempre é possível verificar executando este PowerShell:

$spurl ="https://foo"
$spsite = Get-SPSite $spurl
$realm = Get-SPAuthenticationRealm -ServiceContext $spsite
$realm

A saída será seu realm, seja ele qual for. Por fim, há outra coisa que você pode fazer para verificar: certifique-se de ter criado um appPrincipal para o ClientId usado. Novamente, há um PowerShell que você pode usar para conferir, usando as informações de cabeçalho de WWW-Authenticate acima:

Get-SPAppPrincipal -NameIdentifier <e9134021-0180-4b05-9e7e-0a9e5a524965@8a96481b-6c65-4e78-b2ef-a446adb79b59> -Site https://foo

Caso você obtenha um erro ou não obtenha resultados, saberá que não possui um SPAppPrincipal válido. Crie um usando o PowerShell. Para que o post fique completo, eis um exemplo:

$clientId = "alguma guid criada por você"
$spurl ="https://foo"
$spsite = Get-SPSite $spurl
$realm = Get-SPAuthenticationRealm -ServiceContext $spsite
$fullAppIdentifier = $clientId + <'@'> + $realm
$appPrincipal = Register-SPAppPrincipal -NameIdentifier $fullAppIdentifier -Site $spsite.OpenWeb() -DisplayName "My Cool App"

Com isso, esgoto por hoje minha lista de dicas de solução de problemas de aplicativos de alta confiança. Atualizarei este post assim que (ou se) tiver mais novidades.

 

 

 

 

Este é um post traduzido. O artigo original está em More TroubleShooting Tips for High Trust Apps on SharePoint 2013