單點登入 (SSO) 是大部分大型企業向其使用者（員工、合作伙伴、客戶和承包商）提供的一項重要服務。在 IT 安全制度越來越嚴格的時代裡，SSO 技術的使用使得公司能夠以一種一致的方式跨多個應用程式實施訪問控制策略，這減少了實現的總體成本。這些策略可能包括密碼長度、密碼複雜度、密碼使用時長、以前的密碼的重用等。無論一個應用程式必須遵守哪些規則或策略，您都只需實現一次即可在以後重用。對於利用此 SSO 基礎架構的系統，認證和審計也得到了簡化。
除了 IT 合規性，還能避免重大的風險。您有多少次路過配電室 (cubicle isles)，看到了寫著密碼的便箋？您個人為記住每個企業系統的數百個密碼所選的方法是什麼？在整個企業中擁有 SSO，使您的使用者只需記住一個密碼，這不僅減少了將密碼貼上在配電室牆上的風險，還減少了密碼共享的風險。如果您的電子郵件、人力資源福利制度，以及其他系統都使用同一個密碼，使用者不可能與他（或她）的同事共享該密碼。
在成本節省方面，事實證明 SSO 能夠通過減少服務檯呼叫數量獲得直接的投資回報。更少的不同密碼意味著某人因為忘記密碼而呼叫服務檯的次數更少。多篇 Internet 文章與 Gartner 和 Forrester Research 等公司的報告稱呼叫量可以減少 40% 到 70%。
SSO 的元件
我們首先看看支援 SSO 所需的一些基本的技術元件：
- 使用者。一個嘗試登入的使用者
- Web 應用程式。使用者嘗試登入到的一個應用程式對於本文，將該應用程式想作任何 Java™、Microsoft® .NET、PHP Web 應用程式或軟體即服務 (SaaS) 應用程式，比如 SalesForce.com、Google Apps、Microsoft Office 365、Concur、ServiceNow 或 Workday。
- Web 應用程式代理。對於在企業資料中心內執行的非 SaaS 應用程式，通常安裝在託管該應用程式的 Web 或應用伺服器之上。
- 策略伺服器/SSO 伺服器。提供實現 SSO 所需的所有功能和特性的軟體部分
- 目錄。儲存使用者名稱、密碼和使用者的其他屬性的基礎儲存庫在大部分組織中，您會看到 Active Directory® Domain Services 或其他一些實現輕量級目錄訪問協議 (LDAP) 的目錄軟體。儘管不是最佳實踐，但您也可使用關聯式資料庫表。
圖 1 顯示了這些元件的實際應用。
圖 1. SSO 的高階元件
本文重點介紹用於基於 Web 的應用程式的 SSO（而不是桌面 SSO 或企業 SSO）。在基本層面上，基於 Web 的 SSO 原則遵循 圖 1中所示的架構。讓我們通過一個示例，更具體地分析以下該圖。
SSO 需要的兩個重要元件：策略/SSO 伺服器和 Web 應用程式代理。策略伺服器/SSO 伺服器常常稱為身份決策點 (IDP)。IDP “決定” 使用者憑據（使用者名稱/密碼）是否正確以及使用者是否可以登入。每個大型企業軟體供應商可能都提供了這一領域的部分技術或產品。這一領域的頂級解決方案包括 IBM® Security Access Manager for Enterprise Single Sign-On、CA SiteMinder 和 Oracle Access Management。此外，許多開源和 SaaS 產品正在市場中興起，它們正成為上述產品（OpenAM、Okta、DirectAxs 和 Ping Identity）的重要競爭對手。
上面提及的每個產品都隨帶了自己的代理，這些代理必須安裝在您嘗試保護和為其啟用 SSO 的應用程式的 Web 伺服器和應用伺服器上。一般而言，您將擁有大部分主要作業系統、Web 伺服器軟體和應用伺服器軟體的代理。代理的作用是攔截對一個應用程式的登入請求，然後將該請求傳遞給 SSO 伺服器以制定決策。因此，此元件常常稱為身份執行點。
將 SSO 擴充套件到雲
隨著公司採用越來越多的基於 SaaS 的應用程式，他們希望將自身的 SSO 功能擴充套件到這些應用程式中。這意味著一個使用者可使用其每天早上用於企業應用程式、電子郵件，甚至桌面的相同憑據登入到一個 SaaS 應用程式。
SaaS 供應商認識到了這一需求，提供了一些簡單機制來提供幫助。許多新興的標準使這些整合只需幾小時或幾天即可完成。這至關重要：如果每個 SaaS 供應商都為此整合提供自己的專用方法，後果將無法想象。甚至更糟的是，如果每個 SSO 伺服器供應商提供它自己的技術，會有何後果？這無疑會產生大量諮詢費用。
SaaS 專案通常是受業務驅動的。IT 確實會干預，但有時是在採購週期中的晚期干預。您讓受業務線 (LOB) 支援的 IT 高管通知身份管理 (IDM) 專案經理，表明業務部門已選擇一個新 SaaS 供應商且希望通過 SSO 實現安全登入。該 SaaS 供應商聲稱轉換隻需一天的工作，那麼 IDM 團隊能在下星期完成嗎？
您（IDM 專案經理）同意研究並告知 LOB 高管。您查詢 SaaS 供應商並閱讀它的 SSO 材料。您與架構師進行了快速溝通，所有跡象表明這應能輕鬆完成。
現在，技術人員開始整合。但是，他們很快認識到有許多問題需要解決，並且整合可能要花兩星期時間（顯然不是一兩天）。可能會意外出現的各種問題的示例包括：
- 標準不受支援。在極少的情況下，您會找到一個至少不支援安全性斷言標記語言 (SAML) 的 SaaS 供應商。您常常會發現，SSO 伺服器的最新版本不支援 SAML，或者您的供應商將一個 SAML 封裝為一個獨立的 SKU。那麼您現在必須採購新的 SSO 服務軟體。
- 一個標準受支援，但無法生效。假設您未遇到第一個問題，您也可能會看到，儘管兩方（SSO 伺服器和 SaaS 供應商）都聲稱全面支援一個規範的一個特殊版本，但在您嘗試整合它們時，會遇到一些挑戰。這些挑戰一般較小且可解決，但它們需要支援團隊和 IDM 技術人員舉行一次電話會議來談論。
- 專有技術。一些 SaaS 供應商提供了 Web 服務或目錄同步化來作為 SSO 的一種替代機制。儘管可行，但這些替代機制會導致額外的開發工作，並且必須處理使專案週期變得更長的網路安全性、防火牆和其他問題。
重點很明確：仔細設定預期。SaaS SSO 專案不是一個 24 到 48 小時的任務。實際的工作量可能沒有這麼多，但由於所需的所有協調，總時間很容易達到兩個星期。
設計模式
本節探討在資料中心託管的傳統應用程式與 SaaS 應用程式之間實現 SSO 的 3 種設計方法。您無疑已看到考慮了前面所提及挑戰的已實現模式。
設計模式 1：自定義 Web 應用程式
如果您的 SaaS 提供商或 SSO 軟體不支援 SAML，那麼可使用此設計模式。此外，可使用它來使用 Web 服務或另一種專用整合。此設計模式的最後一個用例是在您的 SaaS 提供商支援 SAML，但您的 SSO 伺服器不支援時。如果您最終決定執行自定義 SAML 實現（不推薦），設計模式將類似於這裡描述的模式。
基本而言，您將部署一個受您的 SSO 軟體所提供的典型 Web 代理保護的 Web 應用程式。此應用程式包含一個登入頁面，並針對 SSO 伺服器進行身份驗證。該應用程式還包含將憑據傳遞給 SaaS 應用程式的程式碼。在使用者經過身份驗證後，該應用程式將身份驗證資訊傳遞給 SaaS 應用程式。當然，始終加密此資料並通過安全套接字層傳輸它。如果 SaaS 提供商支援 SAML，您可使用一個自定義 SAML 實現來生成 SAML，或者，應用程式也可擁有程式碼來使用 SaaS 供應商所提供的 Web 服務。一個最不推薦但可行的技術選項是，結合使用一個 HTTP post 和一些使 SaaS 應用程式能夠識別使用者的基本資訊。
此模式的一種變體是，SaaS 提供商實際提供了此 Web 應用程式。在本質上，此 Web 應用程式與您從 SSO 伺服器產品安裝的代理沒什麼不同，所以可能是構建自定義 Web 應用程式的首選選項。
設計模式 2：基於 SAML
這是理想的解決方案，其中 SAML 用於在 SaaS 應用程式與 SSO 伺服器之間傳輸 SSO 資訊。如果兩方都全面支援 SAML，那麼一次 SAML 設定的執行和測試通常會花幾小時。
這是不同的 SSO 伺服器產品仍在完善的地方。在每個產品週期中，您都會看到更多開箱即用的功能，它們將整合工作縮短到短短 5 分鐘。例如，我只花了一個小時，即將 SalesForce.com、Google Apps 和 Facebook 與一個 SSO 伺服器產品整合完成。如 圖 2 中所示，以下是此模式的工作原理：
- 使用者登入到一個 SaaS 應用程式。
- 以 SAML 請求的形式將請求重定向到您的 IDP（SSO 伺服器）。
- 您的 SSO 伺服器解密 SAML 並對使用者進行身份驗證。
- 伺服器向 SaaS 應用程式返回一個成功或失敗的 SAML 響應。
- 使用者登入成功或看到一條相應的錯誤訊息。
要設定此過程，一般的步驟如下所示：
- 登入到您的 SaaS 提供商的管理控制檯，使用憑據定義您的 SSO 伺服器的 URL。
- 在 SaaS 伺服器和 SSO 伺服器上設定加密的訊息的 SSL 金鑰。
- 在 SSO 伺服器上建立一個策略，為它啟用 SAML 通訊。
- 調整所需的任何其他引數，比如自定義登入和錯誤頁面，以及超時。
如果此過程順利完成，它確實就是這麼簡單。
圖 2. 基於 SAML 的 SSO
設計模式 3：自動化的配給
自動化的配給是目錄同步化設計模式的一種巧妙的替代方案。圖 3 演示了它的工作原理。在載入、傳輸和終止過程中，當一個 IDM 工具將對使用者身份的更改寫入它自己的資料儲存區（通常為目錄軟體）時，它也會將此資訊寫入 SaaS 應用程式，這通常通過一個 Web 服務呼叫完成。使用者增加、終止和密碼更改資訊都會傳送到 SaaS 應用程式，進而與內部目錄保持同步。
現在，當一個使用者登入時，他（或她）可使用公司憑據。此設定實現了一種與 SSO 稍微不同的風格，稱為簡單登入（simple sign-on）（而不是 SSO），簡單，是因為它仍然使用了與公司系統相同的使用者名稱和密碼，但不是單一登入。使用者無需單獨地登入到 SaaS 應用程式。
您可通過自定義 Web 服務實現來實現此模式，或者如果使用的技術支援為此型別的使用者活動使用服務配給標記語言 (Service Provisioning Markup Language, SPML) 標準，也可實現此模式。
圖 3. 自動化的配製
結束語
如果經過了周密計劃，通過 SaaS 提供商建立 SSO 是一個相對輕鬆的任務。但也有許多事務需要注意，並且整個流程需要良好的專案管理和預期設定技能，才能確保專案成功完成。請記住，SaaS 供應商支援 SSO，但不是所有 SaaS 供應商都一致地支援 SAML。因此，一定要在計劃或採購週期開始時就對 SSO 展開技術溝通。需要在兩方之間雙向共享技術限制。
類似地，如果正在構建自定義解決方案，請確保它們是高度安全和加密的。此外，確保您記錄了每個操作。如果和當一些地方出錯或出現登入事務花了太長時間的問題，您希望能夠信任您的日誌。詳細的記錄方法一般會補償花在第一個支援問題上的時間。
最後，如果您看到 SaaS 在您的 IT 領域中具有更為顯著的作用，請提前計劃。更早（而不是更晚）進行正確的技術投資。同樣重要的是，在 SaaS 供應商和商用的現成產品改進其功能時，計劃重組和重新評估。