OAuth 和 SharePoint 2013 中解除凍結的使用者 - 他們如何執行該項動作及我需要知道些什麼

英文原文已於 2012 年 8 月 16 日星期四發佈

首先我想說我喜歡撰寫有關隨機 SharePoint 神秘要點的部落格文章，就是因為我可以使用完全口語化的語言，就像我的部落格標題一樣。除非建立新版本的 SharePoint，否則有些事情幾乎是不可能完成。有人在 SharePoint 2013 中看見有趣的社交訊息嗎？「抱歉讓您久等，我幾乎已經完成了」及類似訊息。我發現更好玩的是其中穿插了像是 HRESULT 我的朋友 Tom 已在不久前的某天取得...之類的訊息。嗯…改變的事情越多，它們越要保持不變。

現在回到目前的主題。當我在討論一些新的 SharePoint 2013 功能時，已經在這個部落格中提及 oAuth 一或兩次。但是我仍然不會徹底討論「什麼是 oAuth」，因為我們有一整個小組的文件工程師正在做這方面的努力，所以我只想要再次稍微補充一些使用它的方法。oAuth 信任的最佳範例或許是適用於搜尋的「遠端 SharePoint 索引」- 這可允許某個伺服器陣列中的人發出要路由到其他 SharePoint 伺服器陣列的查詢，而且在該遠端 SharePoint 伺服器陣列中，能夠重新建構使用者的身分識別，如此一來，搜尋結果便能適當地進行安全性調整。它也可以用於其他像是新的應用程式模型 (例如，讓這位使用者有權存取應用程式所要求的內容) 的案例中、在像是 SharePoint 與 Exchange 的伺服器應用程式之間使用 (讓這位使用者具備信箱內容的權限)，以及許多其他項目。「遠端 SharePoint 索引」對我而言還是一個很好的範例，因為我認為它或許是用來想像為什麼我們需要執行我們所做的動作，才能讓所有事情如預期般運作的最佳案例。

因此，讓我們從頭開始 - FarmA 如何「製作一個 Steve」讓它看起來像是 FarmB 上的 “Steve” ？好的，這一切都要從使用者設定檔應用程式開始說起。假設 Steve 位於 FarmB 上並發出一個查詢。該查詢會傳送到 FarmA，且該查詢中隨附一些關於 Steve 的屬性。根據預設，這些屬性將會是 Steve 的 SMTP 位址、SIP 位址、帳戶名稱及名稱識別碼。當 FarmA 取得該要求時，第一件要做的事是在它的本機使用者設定檔應用程式中執行查閱；它將尋找符合所傳送之 Steve 的值的設定檔。這就是為什麼務必要確定您的 UPA 的狀況良好且已填入 SharePoint 2013，以及為什麼我要撰寫這篇關於如何執行此動作的原因了：https://blogs.msdn.com/b/sharepoint_cht/archive/2012/09/20/sharepoint-2013-ad-saml.aspx。

好的，現在 FarmA 已經找到 Steve 使用者設定檔，它可以使用這個設定檔來做什麼？嗯，從這裡得到的答案是「看情況」，那麼，為什麼針對組織的這個方面進行規劃是如此重要。它所根據的項目是您使用的驗證類型 - 以下提供作法：

• Windows 宣告 - 如果您使用 Windows 宣告，則在大多數情況下，您需要的所有資訊都位於使用者設定檔中。它擁有您的帳戶名稱，並擁有您的 AD 群組成員資格。至於我所謂的「在大多數情況下」是什麼意思，我將會多解釋一點。但簡單來說，就是如果您使用 Windows 宣告，則您相當厲害。
• 表單型驗證宣告 - 如果您使用 FBA，則有些事是您需要知道的。首先是需要一種可填入您的 UPA 並讓它保持最新狀態的方法。如果您剛開始將 FBA 與 LDAP 提供者搭配使用，而且您的目錄實際上是 Windows Active Directory，則您是處於最佳狀態。您可以建立連至 Active Directory 的設定檔連線，只需利用我在上述內容中連結之文章中所述內容的類似行為，將它與 FBA 提供者產生關聯即可。在大多數情況下，AD 不會成為您的提供者，這表示您必須撰寫一些自訂程式碼來填入 UPA。這應該足以讓您取得對於 FBA 使用者而言應該真正關心的唯一屬性，那就是帳戶名稱。大家都知道，「在大多數情況下」(再次略加說明)，您剩餘的資料部分會來自角色提供者。嗯，我們在此處所做的真正酷的事是當我們解除凍結 FBA 使用者時，也會叫用相關聯的角色提供者，因此，它就像是本機登入的 FBA 使用者。這讓我們能夠捕捉所有適用於 FBA 使用者的角色宣告。
• SAML 宣告 - 這個案例與 FBA 類似，而您第一件需要做的事就是填入您的 UPA。如果您夠幸運，您的使用者會位於 AD 中，而您只需遵循上述連結之部落格文章中的指導方針來直接匯入它們。如果您不夠幸運，則需要尋找連線至來源目錄並從該處匯入的方式。當然，這可能是最複雜的 SAML 宣告，因為您可能會有一到多個目錄，而您甚至未擁有它們全部 (例如，或許您有合作夥伴、與 ACS 同盟，以及使用 Facebook 或其他提供者等等)。即使如此，如果您想要讓這所有「東西」運作，則需要找到填入 UPA 的方法。這裡還有第二個重點 - 當您登入為 SAML 使用者時，會向您的身分識別提供者 (IdP) 取得一組宣告。這個使用者解除凍結程序無法模擬該項登入。這就是 SAML 的本質，對吧 - 您可能被一或多次重新導向，並提供我們未加以說明之任意數目的驗證提示與驗證類型 (像是雙重要素驗證)。因此，這對您有何意義？如果您要使用宣告來保護內容安全並透過這個使用者解除凍結程序來授權該內容的存取權，則您真的需要透過宣告增強來新增宣告。您無法在解除凍結期間從 IdP 取得宣告，因此，如果您需要它們，則需本機授與它們。這就是我在上述內容中提及的「在大多數情況下」，而我現在將進行解釋。
• 「在大多數情況下」- 這是什麼意思？嗯，希望它現在已經變得更明確 - 不論您是否為 Windows 使用者、FBA 使用者或 SAML 使用者，除了向驗證提供者取得的宣告之外，您也可以透過增強來新增其他宣告：https://blogs.technet.com/b/speschka/archive/2010/03/13/writing-a-custom-claims-provider-for-sharepoint-2010-part-1.aspx (可能為英文網頁)。另一件我們要在解除凍結期間執行的事是叫用所有已註冊的自訂宣告提供者，如此一來，我們也可以針對解除凍結的使用者捕捉其他宣告，如果這些使用者已經本機登入並叫用這些提供者，則他們將會收到宣告。

這就是為什麼我如此喜愛「遠端 SharePoint 索引」案例的原因，而我將在此處說明所需的規劃。您可以想像，在伺服器陣列內，您可能會根據 Windows 群組、FBA 角色、SAML 宣告或任何透過增強新增的宣告來授與內容的權限。如果您在查詢內容時未擁有這些宣告，則系統將對它進行安全性調整，而您將不會看見它。因此，您可以看見當您本機登入時所授與之每個宣告的重要性，您也可以在我們解除凍結您的版本時取得宣告。

有許多可能的規劃方式可讓這所有的一切運作，因此，希望這篇文章可協助您識別主要作用組件，讓您能夠了解要將重點放在何處。

這是翻譯後的部落格文章。英文原文請參閱 OAuth and the Rehydrated User in SharePoint 2013 – How’d They do That and What do I Need to Know