- 首頁
- /
- 文章
使用 Shibboleth 設定 Control Hub 中的單一登入
您可以在 Control Hub 和使用 Shibboleth 來作為身分識別提供者 (IdP) 的部署之間設定「單一登入 (SSO)」整合。
單一登入與 Control Hub
單一登入 (SSO) 是階段作業或使用者驗證程序,允許使用者提供認證來存取一或多個應用程式。此程序會針對使用者取得權限的所有應用程式,進行使用者驗證。如果使用者在特定階段作業期間切換應用程式,則此程序會消除進一步的提示。
「安全性聲明標記語言 (SAML 2.0) 同盟通訊協定」用於在 Webex 雲端和您的身分識別提供者 (IdP) 之間提供 SSO 驗證。
設定檔
Webex 應用程式僅支援 Web 瀏覽器 SSO 設定檔。在 Webex 瀏覽器 SSO 設定檔中,Webex 應用程式支援下列繫結:
-
SP 起始的 POST -> POST 連結
-
SP 起始的 REDIRECT -> POST 連結
NameID 格式
「SAML 2.0 通訊協定」支援特定使用者採用數種 NameID 格式進行通訊。Webex 應用程式支援下列 NameID 格式。
-
urn:oasis:names:tc:SAML:2.0:nameid-format:transient -
urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified -
urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress
在您從 IdP 載入的中繼資料中,第一個項目是設定用於 Webex。
SingleLogout
Webex 應用程式支援單一登出設定檔。在 Webex 應用程式中,使用者可以登出應用程式,這將使用「SAML 單一登出」通訊協定來結束階段作業,並向您的 IdP 確認該登出。請確保為 SingleLogout 設定了 IdP。
將 Control Hub 與 Shibboleth 整合
該設定指南顯示 SSO 整合的特定範例,但不提供所有可能性的詳盡設定。例如,記錄了 nameid-format urn:oasis:names:tc:SAML:2.0:nameid-format:transient 的整合步驟。其他格式(例如 urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified or urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress )適用於 SSO 集成,但超出了我們文件的範圍。
為 Webex 組織中的使用者設定此整合(包括 Webex 應用程式、Webex Meetings 及在 Control Hub 中管理的其他服務)。如果 Webex 網站已整合在 Control Hub 中,則 Webex 網站會繼承使用者管理。如果您無法以此方式存取 Webex Meetings 且它未在 Control Hub 中進行管理,則您必須執行單獨整合才能為 Webex Meetings 啟用 SSO。
這些整合步驟將安裝有 Tomcat 7 的 CentOS 7 上的 Shibboleth 2.4.5 作為 Web 伺服器。
在開始之前
對於 SSO 及 Control Hub,IdP 必須符合 SAML 2.0 規格。此外,必須以下列方式設定 IdP:
下載 Webex 中繼資料至您的本機系統
在 Shibboleth 檔案中設定授權
安裝 Shibboleth 後,系統會向您提供含有範例的設定檔。
| 1 |
移至目錄 /opt/shibboleth-idp/conf 以存取範例檔。 |
| 2 |
決定要使用的授權方法 — 例如:LDAP 連結至 Active Directory。 |
| 3 |
編輯 handler.xml 檔,如下所示: 取消註解 意見 |
| 4 |
填寫 Active Directory 的詳細資料以允許驗證。提供設定給檔案 login.config。
|
為 SAML 聲明設定 Shibboleth 服務提供者元件
| 1 |
將您從 Webex SP 下載的檔案新增至目錄 /opt/shibboleth-idp/metadata。 |
| 2 |
編輯 relying-party.xml 檔案;在 DefaultRelyingParty 標籤後,新增 Webex 的 SAML 斷言的詳細資訊。
對於 ID,必須使用 Webex 中繼資料檔中的 EntityID 值。將範例的 ID 取代為組織的 EntityID。 |
| 3 |
在 metadata:MetadataProvider 標籤內部,新增檔案的位置:
您在 attribute-resolver.xml 中建立的規則應該具有將 mail-attr 屬性發佈到與 Webex 相符的 EntityID 的策略。 |
| 5 |
從 Shibboleth 伺服器上的 /opt/shibboleth-idp/metadata 下載中繼資料檔。檔名為 idp-metadata.xml。 |
匯入 IdP 中繼資料並在測試後啟用單一登入
匯出 Webex 中繼資料後,設定 IdP,然後將 IdP 中繼資料下載至本機系統,您便可以將中繼資料匯入至 Webex 組織(從 Control Hub)。
在開始之前
請勿從身分識別提供者 (IdP) 介面測試 SSO 整合。我們只支援由服務提供者發起(即由 SP 發起)的流程,因此您必須對此整合使用 Control Hub SSO 測試。
| 1 |
選擇一個:
|
| 2 |
在匯入 IdP 元資料頁面上,將 IdP 元資料檔案拖曳到頁面上,或使用檔案瀏覽器選項來尋找並上傳元資料檔案。按一下下一步。
如果可以,您應該使用較安全選項。這只有在您的 IdP 使用公用 CA 來簽署其中繼資料時才可行。 在所有其他情況下,您必須使用較不安全選項。這包括中繼資料未簽署、自我簽署或由私人 CA 簽署這樣的情況。 Okta 未簽署中繼資料,因此您必須為 Okta SSO 整合選擇較不安全。 |
| 3 |
選擇 測試 SSO 設定,當開啟新的瀏覽器標籤時,透過登入向 IdP 進行身份驗證。 如果您收到驗證錯誤,則憑證可能有問題。檢查使用者名稱和密碼並再試一次。 Webex 應用程式錯誤通常表示 SSO 設定有問題。在這種情況下,再次檢查這些步驟,尤其是複製 Control Hub 中繼資料並貼至 IdP 設定的步驟。 若要直接查看 SSO 登入體驗,您還可以從此螢幕按一下將 URL 複製到剪貼簿,並將其貼至私人瀏覽器視窗中。您可以在這裡使用 SSO 進行逐步登入。此步驟會停止因存取權杖可能位在現有階段作業中而您未進行登入的誤判。 |
| 4 |
回到 Control Hub 瀏覽器標籤。
此 SSO 設定不會在貴組織中生效,除非您先選擇圓鈕並啟動 SSO。 |
後續動作
如果您想要將 Okta 以外的使用者佈建至 Webex 雲端,請使用將 Okta 使用者同步至 Cisco Webex Control Hub 中的程序。
如果您想要將使用者從 Entra ID 設定到 Webex 雲,請使用 將 Microsoft Entra ID 使用者同步到 Cisco Webex Control Hub 中的步驟。
您可以按照 抑制自動電子郵件 中的步驟來停用發送給組織中新 Webex 應用程式使用者的電子郵件。文件還包含將通訊傳送給您組織中的使用者的最佳做法。