Altri suggerimenti per la risoluzione dei problemi per app con livello di attendibilità elevato in SharePoint 2013

Articolo originale pubblicato venerdì 2 novembre 2012

Sono uno sviluppatore di app e adoro le attività di sviluppo, ma credo che diventerò rauco a forza di gridare al computer se dovrò ancora affrontare un problema di tipo "L'autorità emittente del token non è attendibile" con le mie nuove app di SharePoint. Per non danneggiare la vostra voce e il vostro equilibrio, vi elencherò qui una serie di elementi che verifico quando riscontro questo problema. Man mano che scoprirò nuovi modi per evocare e risolvere questo errore, aggiornerò il post e segnalerò la modifica con il contrassegno "AGGIORNATO" di seguito.

È importante ricordare che con l'espressione "app con livello di attendibilità elevato" intendo che NON utilizzate ACS come broker di trust per l'app di SharePoint. Create invece il token OAuth e lo firmate con il vostro certificato. Questo processo è già stato documentato interamente in un'altra occasione per cui non lo descriverò di nuovo qui. Presumo che abbiate già letto in proposito e che abbiate tentato con scarsi risultati. Detto questo, ecco alcuni casi in cui ho riscontrato questo errore:

1. Aggiunta all'elenco SPTrustedRootAuthority: quando utilizzate un certificato per firmare i token OAuth, dovete creare un elemento New-SPTrustedRootAuthority. Come per New-SPTrustedIdentityTokenIssuer in SharePoint 2010, è necessario aggiungere il certificato per la firma di token e ogni certificato della catena all'elenco di SharePoint di autorità attendibili. Ho descritto gli stessi passaggi di questo processo in questo post: https://blogs.technet.com/b/speschka/archive/2010/02/13/root-of-certificate-chain-not-trusted-error-with-claims-authentication.aspx. Ignorate la parte relativa all'esportazione del certificato da ADFS, poiché suppongo abbiate creato il certificato per le app con livello di attendibilità elevato con altri mezzi, CA di radice pubblica come GoDaddy, VeriSign e così via, certificati autofirmati o emessi da dominio.
2. ID client composto da tutti caratteri maiuscoli: come ho indicato in un altro post, assicuratevi di NON utilizzare lettere maiuscole quando inserite l'ID client nel file AppManifest.xml dell'applicazione o nel file web.config dell'applicazione Web se create una soluzione self-hosted. Per ulteriori dettagli, leggete: 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. Autorità emittente del token non configurata come broker di trust: ho descritto anche questo problema in un altro post, a questo indirizzo: 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. È importante verificare di includere il flag -IsTrustBroker quando si crea New-SPTrustedSecurityTokenIssuer.
4. AGGIORNATO: Chiave IssuerId mancante in web.config: per utilizzare la funzionalità di broker delle app in SharePoint 2013, l'applicazione deve conoscere il valore IssuerId del broker di trust quando crea il token JWT inviato a SharePoint. Per conoscerlo, cerca una proprietà dell'app chiamata IssuerId in web.config. Si trova nello stesso posto nel file web.config dell'applicazione in cui si trovano ClientId, ClientSecret e così via e ha l'aspetto seguente: <add key="IssuerId" value="e9134021-0180-4b05-9e7e-0a9e5a524965"/>.
5. AGGIORNATO: Utilizzo dell'anteprima RTM degli Strumenti di Office per Visual Studio: effettivamente è presente un bug nell'anteprima RTM che viene risolto nell'anteprima 2. Il codice che invia il token di autorizzazione a SharePoint non cerca l'elemento IssuerId in web.config, ma invia un valore diverso. Non è importante sapere ciò che invia e perché, ma che per evitare questo problema con questa versione degli strumenti occorre utilizzare sempre il valore IssuerId per SPTrustedSecurityTokenIssuer nella chiave ClientId del file web.config. Man mano che disponete delle parti dell'anteprima 2, installatele direttamente e modificate il ClientId in un GUID univoco che create e registrate (con Register-SPAppPrincipal come illustrato di seguito). È opportuno che i ClientId non siano tutti uguali perché identificano l'applicazione che ha firmato il token OAuth e sono utilizzati nell'intera interfaccia utente di SharePoint. Nel caso fosse necessario eseguire attività di risoluzione dei problemi o controllo, il fatto che tutte le app utilizzino lo stesso valore costituirà un problema.

È anche importante sottolineare un problema correlato: supponete che, nonostante riteniate di avere superato l'errore, venga visualizzato un errore di Accesso negato quando tentate di recuperare contenuto da un sito di SharePoint nell'applicazione self-hosted. Ciò può significare che:

1. il valore ClientId nel file AppManifest.xml per l'app SharePoint non corrisponde al valore ClientId nel file web.config per l'app self-hosted. Stiamo apportando miglioramenti agli strumenti di Visual Studio che dovrebbero risolvere questo problema.

Una domanda ugualmente valida riguarda come tenere traccia di questo problema quando accade. Se fosse facile, non sarei rauco e non insulterei il monitor. Vi indico qui le migliori origini di dati che ho trovato finora da usare quando si verifica questo problema. Se troverò nuovi elementi li aggiungerò all'elenco:

1. Log ULS: è sempre bello, soprattutto durante le feste, aprire i log ULS e ammirare il puro volume di dati. Lo so, questo è sarcasmo. Ciò che si può fare davvero è andare in Amministrazione centrale, Monitoraggio, Configura registrazione diagnostica. Espandere la categoria SharePoint Foundation e selezionare gli elementi seguenti: Autenticazione app, Autenticazione applicazione, Autorizzazione autenticazione e Autenticazione attestazioni. Impostare il livello di registrazione e traccia su Dettagliato per questi elementi e salvare le modifiche, quindi provare ad avviare di nuovo l'applicazione. Utilizzando uno dei molti strumenti di visualizzazione dei log ULS osservare l'elaborazione della richiesta. È un ottimo modo per raccogliere suggerimenti sui problemi di autenticazione dell'app.
2. Fiddler: anche Fiddler è molto utile per queste situazioni. Ciò che vedrete con più frequenza è un errore 401 non autorizzato (come ogni volta in cui il problema sottostante è "L'autorità emittente del token non è attendibile"). Se osservate l'ultimo frame della richiesta e fate clic sulla scheda Intestazioni nel frame Risposta, vedrete un cookie WWW-Authenticate simile a quanto segue: 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>" . Da questo cookie potete capire che il valore ClientId è e9134021-0180-4b05-9e7e-0a9e5a524965 e l'area di autenticazione è 8a96481b-6c65-4e78-b2ef-a446adb79b59. Il valore ClientId è facile da controllare: potete cercare nel file AppManifest.xml e nel file web.config per l'app self-hosted. È altamente improbabile che l'area di autenticazione sia errata, ma potete comunque verificare eseguendo questo PowerShell:

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

Sullo schermo verrà visualizzata la vostra area di autenticazione. Infine, potete eseguire un'altra operazione per verificare: controllare che sia presente un appPrincipal creato per il ClientId in uso. A tale scopo, di seguito trovate un codice PowerShell da utilizzare con le informazioni dell'intestazione WWW-Authenticate riportate sopra:

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

Se viene restituito un errore o non si ottengono risultati, significa che non è presente un SPAppPrincipal valido e che occorre crearne uno utilizzando PowerShell. Di seguito riporto un esempio:

$clientId = "some guid you create"
$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"

Con questo, il mio elenco di suggerimenti per la risoluzione dei problemi delle app con livello di attendibilità elevato è completo per ora. Quando e se avrò altre notizie in proposito, aggiornerò il post.

 

 

 

 

Questo è un post di blog localizzato. Consultate l'articolo originale: More TroubleShooting Tips for High Trust Apps on SharePoint 2013