Partilhar via

在 SharePoint 2013 中規劃新應用程式模型所需的基礎結構

  • Artigo

英文原文已於 2012 年 9 月 4 日星期二發佈

SharePoint 2013 引進全新的應用程式模型，我們姑且稱之為「應用程式模型」或「雲端應用程式模型」。就開發觀點而言，該模型可帶來一整個新系列的商機，與此同時，也提供所需規劃及建立的基礎結構需求，以便支援這些商機。在實際思考應用程式模型時，我真正著重於下列三大面向：

  1. 開發模型 – 開發模型的相關事項牽涉到要如何開發應用程式、要利用哪些新功能等。此作業是一項開發者活動。
  2. 安全性模型 – 對這些新的應用程式而言，安全性模型是很有意思的「事項」組合。您可擁有應用程式主體的新概念，這就是您對應用程式權利所定義的方式。其中的 OAuth 模型定義您可取得的內容，以及定義呈現 SharePoint 所需的機制，SharePoint 帶有描述您身分的 Token，該模型像極了應用程式的宣告。視應用程式是否裝載於 SharePoint 或其他位置，以及是否使用存取控制服務 (ACS) 作為信任代理人的狀況而定，這些 Token 賴以建立和呈現的安全性模型和工具會大不相同。這其中的事項眾多，我不打算在本文中一一介紹，但是，這些項目不但是一項開發者的活動，也是 IT 專業人員的活動。
  3. 基礎結構 – 我們在這裡要探討的是讓應用程式得以在組織內運作的所有「零件」。其中包括服務應用程式、應用程式網域和前置詞、DNS、SSL 和 Web 應用程式設定。基礎結構主為一項 IT 專業人員活動，它也是本部落格文章的基礎。本文也要將焦點集中在裝載於 SharePoint 本身的應用程式，以及裝載於外部其他網站或 Windows Azure 等雲端設施的應用程式上。當您安裝裝載於 SharePoint 的應用程式時，系統會為其建立新的 SPWeb。藉此每個應用程式可取得自己的資料集，應用程式無法寫入其他應用程式的資料。應用程式也會提供安全性階層，以避免擁有某一應用程式權利的人員取得使用目前使用者權利的惡意程式碼，這樣可防止他們在伺服器陣列中存取其他網站的資料。對於以新的應用程式模型為基礎所建立的應用程式，這是一項須牢記的重要基礎原則，當應用程式裝載於 SharePoint 中時，一個應用程式等於 一個 SPWeb。

現在讓我們來探討這些不同基礎結構元件的清單。首先您需確認您擁有在伺服器陣列中建立和執行的「應用程式管理」和「訂閱設定」服務應用程式執行個體。應用程式管理服務可使用於應用程式和部署、授權等追蹤作業之類的事項。「訂閱設定」服務是和用於多組織用戶管理部署作業中的相同服務應用程式，而應用程式該模型也使用該服務建立由應用程式所使用的唯一 URL。

那麼這些 URL 是如何建立的？建立作業是始於您在管理中心所進行的應用程式設定。當您前往管理中心，您會看到一個名為「應用程式」的新區段。如果您按一下該區段，就會看到用以設定應用程式 URL 的選項。您會在那裡找到用來建立應用程式 URL 的兩項値：應用程式網域和應用程式前置詞。應用程式網域與即將用於陣列中所有應用程式的主機名稱很類似。當您規畫命名時，有三項需考量的事項：

  1. 因為名稱用於整個伺服器陣列，所以該名稱取得的層級，須與您針對其他 Web 應用程式所使用的規劃和思考層級相同。
  2. 此外，該名稱必須為完整網域名稱，您會發現，針對此作業嘗試使用 NetBIOS 樣式名稱對於名稱解決方案而言，並不是理想的方式。
  3. 最後，名稱不得為 Web 應用程式的子網域。

讓我們來看看一個特別的範例。假設您的 Web 應用程式看起來像 team.contoso.com、my.contoso.com 和 portal.contoso.com 這般。首先，您可能不會只想讓您的應用程式網域使用 “contoso.com”，因為要這麼做，您就必須為指向您應用程式端點的所有 contoso.com 建立萬用字元 DNS 項目 (一分鐘有更多)。您也不會想要使用 “apps.contoso.com” 之類的名稱，因為那是您針對 Web 應用程式使用的子網域 (全以 “contoso.com” 為根)。所以考量這些規則所得的較佳選擇就是 “contosoapps.com”。

應用程式前置詞值可以是您想要任何值，它會插入應用程式 URL 的第一個部分，我們稍後會加以討論。

我在上面提到使用萬用字元 DNS 項目，這就是下一個部分要涵蓋的主題。當應用程式安裝完畢，且該應用程式裝載於 SharePoint 中時，就會如同 https://apps-87e90ada14c175.contosoapps.com/myapp/pages/default.aspx 此類的 URL。URL 的組成元素細分如下：

  • apps：此為上述在管理中心輸入的應用程式前置詞值。
  • 87e90ada14c175：此為以應用程式安裝所在的網站集合和網頁為依據的唯一值。
  • contosoapps.com：此為您在管理中心中輸入的應用程式網域。
  • myapp：此為已安裝應用程式的名稱。剩下的 URL (ages/default.aspx) 則是包含於應用程式安裝所在的 SPWeb 中的名稱。

在檢視 URL 和其組成方式時，希望您可了解為何要使用萬用字元 DNS 項目。因為所安裝之每個單一應用程式執行個體 URL 的第一個部分皆不相同，即使相同的應用程式安裝於多個網站集合中亦然，為每個單一執行個體持續更新 DNS 並非可行方式。所以這裡要強調的是，對於我在這裡所描述案例的 DNS，您會想要針對 *.contosoapps.com 使用萬用字元 DNS 項目。此項目指向的 IP 位址是我們即將討論的主題。

萬用字元 SSL 項目與萬用字元 DNS 項目相關。為了完全釐清重點，請您注意：如果您正在執行應用程式，您就必須使用 SSL。應用程式模型會涉及 OAuth 存取 Token 的傳送，此 Token 會描述目前使用者和應用程式的身分。就好像您在為使用者傳送 SAML Token 一樣，您會想要加密這些 Token 流經的通道，以避免任何種類的重播形式攻擊，防止外部人員取得內容的存取權探查您的網路流量。使用 SSL 可避免這些情況發生，且因為您已知道這些應用程式的 URL 對每個已安裝的執行個體而言皆有所不同，因此為了能夠加以管理，您需使用萬用字元 SSL 憑證。再次強調，在我們的案例中，必須針對 *.contosoapps.com 取得萬用字元 SSL 憑證。

到目前為止我們已談論過所需的服務應用程式、應用程式網域和前置詞所需的設定、URL 組成的方式和所需的 DNS 及 SSL 項目。現在，為了連貫這一切，我們需談談路由應用程式要求的方式。一般而言，單就進行應用程式要求的路由作業，您需使用個別的 SharePoint Web 應用程式。讓我們來了解其原因。再次假設您有定義如下的三個 Web 應用程式，這些應用程式皆使用 SSL，因此每個應用程式皆使用唯一的 IP 位址：

  • team.contoso.com – 192.168.1.10
  • my.contoso.com – 192.168.1.11
  • portal.contoso.com – 192.168.1.12

如上所述，您現在僅可在伺服器陣列中擁有一個應用程式網域，且其不得為子網域。這樣會在上列應用程式產生兩個非常實際的問題：

  • 如果我們在這些 Web 應用程式的每個中安裝應用程式，要如何取得路由至正確 Web 應用程式的正確應用程式要求？我們僅有一個應用程式網域，但有三個 Web 應用程式。
  • 如果我們嘗試將應用程式要求路由至這些現有 Web 應用程式其中之一，就會打破 SSL 的規定。為什麼？因為既然我們在所有 Web 應用程式上使用 SSL (既然我們使用應用程式)，這些應用程式皆會有 *.contoso.com 之類的 SSL 憑證。所以我們無論如何皆無法將應用程式要求路由至應用程式，因為您無法取得可同時在 *.contoso.com 和 *.contosoapps.com 運作的 SSL 萬用字元，而這將是我們應用程式即將使用的萬用字元。

解決方式為建立第四個 Web 應用程式。您可以建立該程式而無需使用主機標頭名稱，並為其指定 192.168.1.13 的共用 IP。然後在 DNS 中 *.contosoapps.com 的萬用字元項目就會指向 192.168.1.13。最後會發生的結果，就是您的 App Web 應用程式會「接聽」IP 位址，而負責路由的 SharePoint http 模組會接聽應用程式的要求。接著應用程式會使用 App 管理服務應用程式，判定哪個 Web 應用程式實際上正在裝載該應用程式，並將要求重新路由至應用程式。然後要求就會從 Web 應用程式、網站集合和應用程式本身所存在的 SPWeb 來進行處理，則所有針對這些項目的安全性和驗證設定就會正確套用。

現在我們的伺服器陣列設定看起來就像這樣：

  •  應用程式設定
    • 應用程式網域 – contosoapps.com
    • 應用程式前置詞 – 應用程式
  • Web 應用程式

    • team.contoso.com

      • IP 位址：192.168.1.10
      • SSL 憑證：*.contoso.com

    • my.contoso.com

      • IP 位址：192.168.1.11
      • SSL 憑證：*.contoso.com

    • portal.contoso.com

      • IP 位址：192.168.1.12
      • SSL 憑證：*.contoso.com

    • 您無需使用主機標頭，或者您可使用 contosoapps 等之類的名稱，這點並不那麼重要，因為路由作業並非依據主機標頭，而是依據 IP 位址來進行。不過，如果您使用了主機標頭，且所有 Web 應用程式使用相同的 IP 位址，則此接聽程式 Web 應用程式就完全不得擁有任何主機標頭值！ 否則 IIS 就不會接聽任何 Web 應用程式的應用程式要求。

      • IP 位址：192.168.1.13
      • SSL 憑證：*.contosoapps.com
  • DNS
    • team.contoso.com – 192.168.1.10
    • my.contoso.com – 192.168.1.11
    • portal.contoso.com – 192.168.1.12
    • *.contosoapps.com – 192.168.1.13

至此，我們已涵蓋基礎結構設定的所有面向，但在為 SharePoint 2013 新應用程式的首度發行進行規劃時，您需牢記一些其他的考量項目：

  • SharePoint 應用程式無法在使用 SAML 的 Web 應用程式上運作。如果您使用 SAML 驗證，您就無法在那些 Web 應用程式上使用 SharePoint 應用程式。希望在日後的 Service Pack 或特定其他類型的修補程式中可解決此問題，但目前該問題仍屬 SharePoint 2013 RTM 的功能限制。
  • SharePoint 應用程式不支援多重區域 (亦即 AAM)，所有要求皆在預設區域之外處理。如果您使用 AAM 以支援多重區域，則您可能會無法使用 SharePoint 應用程式。所有應用程式會在預設區域以外加以處理，所以理論上如果您將預設區域開放，讓所有人皆可進入，且您在每個區域使用完全相同的驗證機制 (其中有些可能具有的限制因過於瑣碎，目前不在此處加以介紹)，則應用程式有可能可以運作。但再次提醒您，如果您使用區域，通常是因為 a) 您不想對每個人開放每個端點，或 b) 您不想要使用不同的驗證方法。再強調一次，日後這個情況可能發生改變，但是 SharePoint 2013 RTM 目前只提供這樣的使用條件。

 

另外一項重點，也是最後的注意事項，看起來就像是一大堆的設定作業，而事實上就是如此。不過您必須牢記，如果您使用 Office 365，則所有這些項目都會為您處理到好，不用慌、不必亂，只需輕鬆安裝並使用應用程式。您在衡量選擇時，應當對這個優點多加考量。

到這裡您已全部了解，SharePoint 應用程式是 SharePoint 2013 的一大環節，但使用這些應用程式時需進行事前的規劃和設計工作，來確保基礎結構已就緒可支援應用程式。

 

這是翻譯後的部落格文章。英文原文請參閱 Planning the Infrastructure Required for the new App Model in SharePoint 2013