Partilhar via

更多有關 SharePoint 2013 中高信任度應用程式的疑難排解祕訣

  • Artigo

英文原文已於 2012 年 11 月 2 日星期五發佈

嗨，我是一位應用程式設計人員，我喜歡進行開發，但是，老實說 - 如果我需要追蹤一個以上有關新 SharePoint 應用程式的「Token 的發行者不是受信任發行者」問題，那麼我可能會對著電腦大聲嘶吼。為了嘗試協助您保護您的聲音 (和理智)，我將從此處列出的事項清單開始 (這是我在遇到此問題時所查看的清單)。當我發現引發此問題和可解決該問題之令人興奮的新方法時，就會更新此處的文章，並在下方擲出「已更新！」的字樣。

請務必記住，當我說「高信任度應用程式」時，表示您並未使用 ACS 做為 SharePoint 應用程式的信任代理人；而是您的應用程式會改為建立 OAuth Token 並利用您自己的憑證來簽署它。我知道我們已在他處詳細記載這整個程序，因此不打算在此再次說明此程序。我將假設您已閱讀過該程序且已嘗試執行該程序，而現在您已經準備好來向您的螢幕舉手致敬。但是，話雖如此，我還是會在此處提供看見此錯誤發生的方法：

  1. 新增至 SPTrustedRootAuthority 清單 - 當您使用憑證來簽署 OAuth Token 時，需要建立 New-SPTrustedRootAuthority。就像 SharePoint 2010 中的 New-SPTrustedIdentityTokenIssuer，您需要將 Token 簽署的憑證和鏈結中的每個憑證新增至 SharePoint 的信任授權單位清單。您可以遵循此程序的相同步驟，如同我在下列文章中所述：https://blogs.technet.com/b/speschka/archive/2010/02/13/root-of-certificate-chain-not-trusted-error-with-claims-authentication.aspx (可能為英文網頁)。只需忽略從 ADFS 匯出憑證的相關資訊即可 - 我假設您已經透過某些其他工具，為您的高信任度應用程式建立憑證 - 公用根 CA (例如，GoDaddy、VeriSign 等)、自我簽署憑證或網域發出的憑證。
  2. 用戶端識別碼使用全部大寫的字元 - 如同我在其他文章中所述，請確定當您在應用程式的 AppManifest.xml 檔案中插入用戶端識別碼時，不會使用大寫字母，或者如果您正在建置自我裝載的解決方案，不會在 Web 應用程式的 web.config 中使用大寫字母。如需更多詳細資訊，請參閱 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. 未將 Token 發行者設為信任代理人 - 我曾在下列文章中說明過此問題：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 (可能為英文網頁)。此處的陷阱是確定當您建立 New-SPTrustedSecurityTokenIssuer 時會包含 -IsTrustBroker 旗標。
  4. 已更新！： web.config 中遺漏 IssuerId 金鑰 - 若要在 SharePoint 2013 中使用應用程式的信任代理人功能，您的應用程式在建立要傳送至 SharePoint 的 JWT Token 時必須知道信任代理人的 IssuerId 是什麼。它知道此金鑰的方法是透過查看 web.config 中名為 IssuerId 的應用程式屬性。它可以前往您應用程式之 web.config 中與 ClientId、ClientSecret 等相同的位置。只需查看如下的內容：<add key="IssuerId" value="e9134021-0180-4b05-9e7e-0a9e5a524965"/>。
  5. 已更新！： 使用適用於 Visual Studio 的 Office 工具 RTM Preview - 實際上在 RTM Preview 中某種程度上有一點小錯誤，但已在 Preview 2 中修正。將授權 Token 傳送至 SharePoint 的程式碼不會在 web.config 中尋找 IssuerId 元素，而是會傳送其他值。它傳送的內容及原因實際上並不重要；重要的是，您使用該版本的工具來解決此問題的方式，是一律在 web.config 中針對 ClientId 金鑰的 SPTrustedSecurityTokenIssuer 使用 IssuerId 值。當您取得 Preview 2 時，請立即安裝它們，並將 ClientId 變更為您所建立並登錄的唯一 GUID (利用如下所述的 Register-SPAppPrincipal)。您不想讓 ClientId 全都一樣，因為它會識別哪個應用程式已簽署 OAuth Token,，並在整個 SharePoint UI 中使用。當您需要進行任何疑難排解或稽核時，若所有應用程式都使用相同值，就會發生問題。

現在，還有一個相關問題值得注意：假設您「認為」已經解決此錯誤，但接著在自我裝載的應用程式中嘗試擷取來自 SharePoint 網站的內容時收到「拒絕存取」的錯誤？這可能意味著：

  1. 適用於 SharePoint 應用程式之 AppManifest.xml 檔案中的 ClientId 值，與適用於您自我裝載應用程式之 web.config 中的 ClientId 值不符。我們已對 Visual Studio 工具進行改進， 應該能夠減少發生此問題的情況。

現在，幾乎一樣重要的問題是，我如何在發生這類情況時進行追蹤？喔，如果很容易的話，我就不需要大聲嘶吼，也不需要向我的螢幕舉手致敬了。不過，我已經找到目前可在此問題發生時使用的最佳資料來源。再次提醒，當我找到新資訊時，就會新增至清單中：

  1. ULS 記錄 - 多年來的最愛，特別是在假日聚會時，我喜歡開啟 ULS 記錄，就只是純粹欣賞資料量。好啦，這只是個諷刺罷了。但是，您真正可以做的是移至管理中心、監視、設定診斷記錄。展開 SharePoint Foundation 類別，然後選取下列項目：App Auth、應用程式驗證、驗證授權及宣告驗證。針對這些項目將記錄和追蹤層級設定為 [詳細資料] 並儲存您的變更，然後繼續嘗試再次啟動您的應用程式。擷取數個 ULS 記錄檢視工具之一來查看傳入與處理的要求。蒐集關於您應用程式驗證問題的提示是個好方法。
  2. Fiddler - 也是粉絲的最愛，Fiddler 對於這些情況也很有用。您最常看見的是 401 未經授權的錯誤 (就像每次的基本問題都是「Token 的發行者不是受信任發行者」)。如果您查看要求的最後一個框架，然後按一下 [回應] 框架中的 [標頭] 索引標籤，將看見 WWW-Authenticate Cookie，如下所示： 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>" 。那麼，您可以從中獲得什麼？嗯，我知道在查看此內容時，會預期我的 ClientId 值是 e9134021-0180-4b05-9e7e-0a9e5a524965，並預期我的領域是 8a96481b-6c65-4e78-b2ef-a446adb79b59。ClientId 值很容易檢查 - 我可以查看適用於我的自我裝載應用程式的 AppManifest.xml 檔案和 web.config。雖然不太可能發生領域錯誤的情況，但您一律可透過執下列 PowerShell 來進行驗證：

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

不論領域為何，這樣做都會將領域輸出至畫面。最後，有一件您可以進行驗證的其他事項 - 確定您已針對所使用的 ClientId 建立 appPrincipal。再次提醒，以下是一些您可用來檢查的 PowerShell (這會使用上述的 WWW-Authenticate 標頭)：

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

如果您收到錯誤或沒有產生任何結果，則會知道您不具有效的 SPAppPrincipal，所以需要使用 PowerShell 來建立一個。為了完整起見，以下提供一個範例：

$clientId = "一些您建立的 GUID"
$spurl ="https://foo"
$spsite = Get-SPSite $spurl
$realm = Get-SPAuthenticationRealm -ServiceContext $spsite
$fullAppIdentifier = $clientId + <'@'> + $realm
$appPrincipal = Register-SPAppPrincipal -NameIdentifier $fullAppIdentifier -Site $spsite.OpenWeb() -DisplayName "我的超酷應用程式"

好的，今天光是講解對於高信任度應用程式疑難排解祕訣的清單就已經精疲力竭了 (我也一樣)。當我有更多消息時 (或者如果有的話)，將會更新本文。

 

 

 

 

這是翻譯後的部落格文章。英文原文請參閱 More TroubleShooting Tips for High Trust Apps on SharePoint 2013