SaaS 開發的入門 Web 應用程式

Azure App Service
Microsoft Entra 外部 ID
Azure SQL Database
Azure Logic Apps
Azure Resource Manager

軟體即服務 (SaaS) 是一個複雜的主題,有許多需要考慮點。 在 Azure 上建置 SaaS 解決方案的獨立軟體廠商(ISV)需要解決問題並做出決策,例如:

  • 我應該使用哪一個 租用模型
  • 如何?設定身分識別解決方案以用於多租使用者架構?
  • 如何?處理新客戶的上線?

此架構旨在回答其中一些問題,並提供 SaaS 世界的起點。 此架構可調整以符合各種案例。

潛在的使用案例

以下是您可以使用此架構的一些範例使用案例:

  • 將現有的應用程式現代化,以支援完整多租使用者,作為 SaaS 型商務模型轉變的一部分。
  • 開發全新的 SaaS 供應專案。
  • 將 SaaS 供應專案從另一個雲端服務遷移至 Azure。

架構

Architecture diagram that shows the control plane, identity framework, and end-user S a a S application.

下載此架構的 PowerPoint 檔案

辭彙

下表描述本文中顯示的詞彙。

詞彙 描述 範例
SaaS 廠商或 ISV 擁有 SaaS 應用程式和程式碼並銷售 SaaS 產品的實體。 Contoso Inc,銷售其 SaaS 應用程式:Contoso Tickets。
租用戶 從 SaaS 廠商購買 SaaS 應用程式的實例。 第四家咖啡店。
SaaS 客戶管理員 人員購買或管理應用程式租使用者的人員。 喬,第四咖啡店的老闆。
SaaS 客戶使用者 人員使用應用程式租使用者而不進行管理,且通常屬於與 SaaS 客戶管理員相同的公司或群組。 第四咖啡店的活動經理吉爾和第四咖啡店客戶蘇珊。
終端使用者 SaaS 客戶管理員、SaaS 客戶使用者,或任何其他引進的使用者類型。 這是一般詞彙,用來描述登入應用程式的使用者。 Joe、Jill 和 Susan 都是終端使用者(從 ISV 的觀點)。
前端應用程式 任何前端應用程式。 上線 & 系統管理員應用程式和 SaaS 應用程式都是前端應用程式。

工作流程

  1. SaaS 客戶管理員 會巡覽至裝載于上線 & 系統管理員應用程式 的網站

  2. SaaS 客戶系統管理員 會使用 使用者登入工作流程登入

  3. SaaS 客戶管理員 完成上線流程

  4. SaaS 客戶管理員 會流覽至上線 & 管理應用程式 上的 租使用者系統管理員區域,並將 SaaS 客戶使用者新增 至新建立的租使用者

  5. SaaS 客戶使用者 流覽至 SaaS 應用程式, 並使用 SaaS 應用程式。

使用者登入

使用者登入工作流程包含下列步驟:

Sequence diagram that shows the sign-in process for a user.

  1. 使用者 流覽至 前端應用程式 ,然後選取 [ 登入 ] 按鈕。

  2. 前端應用程式會將 使用者 重新 導向至身分識別提供者 所裝載的 登入頁面。

  3. 使用者 輸入帳戶資訊,並將登入表單提交至 識別提供者

  4. 分識別提供者 發出 POST 要求 ,其中包含 使用者 的電子郵件地址和物件識別碼,以擷取其許可權和角色。

  5. 許可權資料 API 會在許可權資料儲存體 查閱 使用者 的資訊,並傳回指派給該 使用者 的許可權和角色清單。

  6. 分識別提供者 會將許可權和角色新增為自訂宣告至 識別碼權杖 ,也就是 JSON Web 權杖 (JWT)。

  7. 識別 提供者 會將識別碼權杖傳回給 使用者 ,並起始重新導向至 前端應用程式

  8. 終端使用者 會重新導向至前端應用程式 上的 登入端點,並呈現識別碼權杖。

  9. 前端 應用程式 會驗證呈現的識別碼權杖。

  10. 前端 應用程式 會傳回成功的登入頁面 ,而使用者 現在已登入。

如需此登入流程運作方式的詳細資訊,請參閱 OpenID 連線通訊協定

將新租使用者上線

租使用者上線工作流程包含下列步驟:

Sequence diagram that shows the process for tenant onboarding.

  1. SaaS 客戶系統管理員 會流覽至 上線 & 系統管理員應用程式 ,並完成註冊表單。

  2. 架 & 系統管理員應用程式 會向租使用者資料 API 發出 POST 要求 ,以建立新的租使用者。

  3. 使用者資料 API 會在租使用者資料儲存體中建立新的租使用者。

  4. 使用者資料 API 向許可權資料 API 發出 POST 要求 以將 SaaS 客戶管理員 許可權授與新建立的租使用者。

  5. 許可權資料 API 會在許可權資料儲存體 建立新的許可權記錄。

  6. 許可權資料 API 會成功傳回。

  7. 使用者資料 API 已成功傳回。

  8. 架系統管理員應用程式 向電子郵件通知提供者 發出 POST 要求 ,以將「租使用者已建立」的電子郵件訊息傳送給 SaaS 客戶管理員 & 。

  9. 電子郵件 通知提供者 會傳送電子郵件。

  10. 電子郵件 通知提供者 會成功傳回。

  11. 架系統管理員應用程式 會向識別提供者 發出要求 ,以重新 整理 SaaS 客戶管理員 的識別碼權杖,使其包含新建立租使用者的 & JWT 宣告。

  12. 分識別提供者 會向 SaaS 客戶管理員 的電子郵件地址和物件識別碼發出 POST 要求 ,以擷取其許可權和角色。

  13. 許可權資料 API 會在許可權資料儲存體 查閱 SaaS 客戶管理員的資訊,並傳回指派給 SaaS 客戶管理員 的許可權和角色清單。

  14. 分識別提供者 會將許可權和角色新增為識別碼權杖的自訂宣告。

  15. 識別提供者會將 識別碼權杖傳回至 上線 & 管理員應用程式

  16. 架管理應用程式 會將成功訊息和新的識別碼權杖傳回至 SaaS 客戶管理員 & 。

將使用者新增至租使用者

將使用者新增至租使用者工作流程包含下列步驟:

Sequence diagram that shows the addition of a new user to a tenant.

  1. SaaS 客戶管理員要求從上線 & 管理 應用程式 上的 租使用者管理區域查看租使用者清單。

  2. 架系統管理員應用程式 會向租使用者資料 API 發出 GET 要求 ,以取得 SaaS 客戶管理員 的租 使用者清單。 &

  3. 使用者資料 API 會發出許可權資料 API GET 要求,以取得 SaaS 客戶管理員 有權檢視的租 使用者清單。

  4. 許可權資料 API 會傳回租使用者許可權的清單。

  5. 使用者資料 API 會查閱租使用者資料儲存體中的租使用者資訊,並根據收到的租使用者許可權清單傳回租使用者資料清單。

  6. 架系統管理員應用程式 會將租使用者資料清單傳回給 SaaS 客戶管理員 & 。

  7. SaaS 客戶管理員 會從清單中選取租使用者,以將 SaaS 客戶使用者 新增 至 ,並輸入 SaaS 客戶使用者 的電子郵件地址

  8. 架系統管理員應用程式 會向租使用者資料 API 發出 POST 要求 ,以新增指定租使用者上 SaaS 客戶使用者 的許可權 。 &

  9. 使用者資料 API 驗證 SaaS 客戶管理員 對指定的租使用者具有有效的 JWT 宣告,並且具有使用者的寫入權限。

  10. 使用者資料 API 會發出許可權資料 API 的 POST 要求 ,以在指定的租使用者上新增 SaaS 客戶使用者 的許可權

  11. 許可權資料 API 會發出 GET 要求給 識別提供者 ,以透過提供的電子郵件地址來查閱 SaaS 客戶使用者

  12. 識別 提供者 傳回 SaaS 客戶使用者 的物件識別碼。

  13. Permission 資料 API 會使用其物件識別碼,在指定租使用者上 SaaS 客戶使用者 的許可權資料儲存體 新增許可權記錄。

  14. 許可權資料 API 會成功傳回。

  15. 使用者資料 API 已成功傳回。

  16. 線 & 系統管理員應用程式 會成功傳回。

元件

此架構會使用下列 Azure 服務:

  • App Service 可讓您以您選擇的程式設計語言建置及裝載 Web 應用程式和 API 應用程式,而不需要管理基礎結構。

  • Azure Active Directory B2C 可輕鬆地為終端使用者應用程式啟用身分識別和存取管理。

  • Azure SQL 資料庫 是一般用途的關係資料庫受控服務,可支援關聯式資料、空間資料、JSON 和 XML。

  • Azure Logic Apps 可讓您使用簡單的 GUI 工具快速建置功能強大的整合。

替代項目

任何替代選項的有效性都在很大程度上取決於 您想要讓 SaaS 應用程式支援的租用模型 。 以下是實作此解決方案時可遵循的替代方法範例:

  • 目前的解決方案會使用 Azure Active Directory B2C 作為識別提供者。 您可以改用其他識別提供者,例如 Microsoft Entra ID

  • 針對更嚴格的安全性和合規性需求,您可以選擇實作私人網路進行跨服務通訊。

  • 您可以實 作跨服務傳訊的事件驅動架構樣式 ,而不是在服務之間使用 REST 呼叫。

考量

這些考慮會實作 Azure Well-Architected Framework 的要素,這是一組指引原則,您可以遵循這些原則來改善工作負載的品質。 如需詳細資訊,請參閱 Microsoft Azure Well-Architected Framework

安全性

安全性可提供針對蓄意攻擊和濫用寶貴資料和系統的保證。 如需詳細資訊,請參閱 安全性要素 概觀。

此解決方案依賴身分識別作為其安全性架構。 Web 應用程式和 API 的驗證和授權是由 Microsoft 身分識別平臺所控管,該Microsoft 身分識別平臺 負責發行和驗證使用者識別碼權杖(JWT)。

成本最佳化

成本優化是考慮如何減少不必要的費用,並提升營運效率。 如需詳細資訊,請參閱 成本優化要素 概觀。

此解決方案中的元件有一些與其作業相關聯的成本,但大部分 Web 應用程式和 SaaS 解決方案的成本都不大。 此外,您可以管理下列資源設定來控制成本:

  • 您可以調整執行應用程式的 App Service 方案,以符合您需要的輸送量。 此外,如果您需要較高的輸送量,您可以在個別方案上執行每個應用程式,但因此會產生較高的成本。 如需詳細資訊,請參閱 Azure App 服務計畫概觀

  • Azure AD B2C 提供兩個 SKU:進階版 P1 和 進階版 P2。 這兩個 SKU 都包含每月使用中使用者數目的免費額度,但您需要評估每個 SKU 提供哪些功能來判斷使用案例所需的功能。 如需詳細資訊,請參閱 Microsoft Entra 外部 ID定價

  • Azure SQL 有數種購買模型來符合各種使用案例,包括自動調整的能力。 您必須評估自己的資料庫使用量,以確保正確調整其大小。 如需詳細資訊,請參閱 比較以虛擬核心和以 DTU 為基礎的 Azure SQL 資料庫購買模型。

效能效益

效能效率是工作負載調整的能力,以符合使用者以有效率的方式滿足其需求。 如需詳細資訊,請參閱 效能效率要素 概觀。

此架構應該能夠進行調整,以輕鬆滿足大部分中型到中型大型工作負載。 由於架構大多使用 Azure 的平臺 (PaaS) 服務,因此您有許多選項可根據需求和負載來調整解決方案的規模。

針對高輸送量案例,或您需要在多個地理位置為客戶提供服務的案例,您也可以考慮在多個區域中部署應用程式和資料庫。 如需此架構的絕佳範例,請參閱 具有資料庫私人連線 的多區域 Web 應用程式。

部署此案例

如果您想要部署此案例,請參閱 GitHub 上的 Azure SaaS 開發工具組 。 這是此架構的可部署參考實作。

參與者

本文由 Microsoft 維護。 原始投稿人如下。

主體作者:

其他投稿人:

下一步

以下是在 Azure 上建置 SaaS 應用程式的一些其他建議資源: