在此文章中
dropdown icon
單一登入與 Control Hub
    設定檔
    NameID 格式
    SingleLogout
集成控制中樞與希博萊特
下載 Webex 中繼資料至您的本機系統
在希博萊特檔案中設定授權
設定 SAML 宣告的 Shibboleth 服務提供者元件
設定宣告屬性
匯入 IdP 中繼資料並在測試後啟用單一登入
使用 Shibboleth 在控制中心中設定單一登入
list-menu在此文章中
list-menu意見回饋?

您可以在控制中樞與使用 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。

集成控制中樞與希博萊特

該設定指南顯示 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。

整合步驟參考 CentOS 7 中的 Shibboleth 2.4.5,其中 Tomcat 7 作為網絡服務器。

在開始之前

對於 SSO 及 Control Hub,IdP 必須符合 SAML 2.0 規格。此外,必須以下列方式設定 IdP:

下載 Webex 中繼資料至您的本機系統

1

登入 Control Hub。

2

前往 管理 > 安全 > 驗證。

3

轉到 身份提供者 標籤並點擊 啟動 SSO。

4

選擇一個 IdP。

5

選擇貴組織的憑證類型:

  • 由 Cisco 自簽名— 我們推薦此選項。讓我們簽署憑證,這樣您只需要每隔五年續訂一次。
  • 由公共憑證授權單位簽署—更安全,但您需要經常更新元資料(除非您的 IdP 供應商支援信任錨)。

信賴起點是公開金鑰,用作驗證數位簽章憑證的授權單位。如需更多資訊,請參閱您的 IdP 文件。

6

下載中繼資料檔案。

Webex 元資料檔名是 idb-meta-<org-ID>-SP.xml。

在希博萊特檔案中設定授權

安裝 Shibboleth 之後,會提供包含範例的組態檔案。

1

轉到目錄 /opt/shibboleth- idp/conf 以訪問示例文件。

2

決定要使用哪種授權方法,例如,LDAP 繫結至。Active Directory

3

編輯 handler.xml 文件,如下所示:

取消註解

    <!--  Username/password login handler -->
    <ph:LoginHandler xsi:type="ph:UsernamePassword"
                  jaasConfigurationLocation="file:///opt/shibboleth-idp/conf/login.config">  
  <ph:AuthenticationMethod>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
</ph:AuthenticationMethod>
    </ph:LoginHandler>

評論

<ph:LoginHandler xsi:type="ph:RemoteUser"> 
<ph:AuthenticationMethod>urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified</ph:AuthenticationMethod>
    </ph:LoginHandler>
4

填寫您的詳細信Active Directory息以允許驗證。 提供設定給登入 .config 檔案。

ShibUserPassAuth {
   edu.vt.middleware.ldap.jaas.LdapLoginModule required
      ldapUrl="ldap://ad0a.cisco.net:389"
      ssl="false"
      tls="false"
      baseDn="cn=Users,dc=cisco,dc=net"
      subtreeSearch="true"
      userFilter="sAMAccountName={0}"
      bindDn="cn=Administrator,cn=Users,dc=cisco,dc=net"
      bindCredential="ThePassword";
};

設定 SAML 宣告的 Shibboleth 服務提供者元件

1

將您從 Webex SP 下載的檔案新增至目錄 /opt/shibboleth-idp/中繼資料。

2

編輯 relying-party.xml 檔案;在預設的 TrelyingParty 標籤之後,新增 Webex SAML 宣告的詳細資訊。

 <rp:RelyingParty id="https://idbroker.webex.com/ea7c1420-711d-4916-95f8-
22de53230d1e"
              provider="https://shib9a.cisco.net/idp/shibboleth"
              defaultSigningCredentialRef="IdPCredential">
            <rp:ProfileConfiguration xsi:type="saml:SAML2SSOProfile"
                includeAttributeStatement="true"
                assertionLifetime="PT5M" assertionProxyCount="0"
                signResponses="never" signAssertions="always"
                encryptAssertions="conditional" encryptNameIds="never"
                includeConditionsNotBefore="true"/>
        </rp:RelyingParty>

對於 id,您必須使用 Webex 中繼資料檔案中的 EntityID 值。 用組織的 EntityID 取代範例的 ID。

3

在「中繼資料:中繼資料提供者」標籤內,新增檔案的位置:

 <metadata:MetadataProvider id="ShibbolethMetadata" xsi:type="metadata:Chaini
ngMetadataProvider">
        <metadata:MetadataProvider id="IdPMD" xsi:type="metadata:FilesystemMetad
ataProvider" metadataFile="/opt/shibboleth-idp/metadata/idp-metadata.xml" maxRefreshDelay="P1D" />
    <!--     Cisco UCXN Configuration               -->
   <metadata:MetadataProvider xsi:type="FilesystemMetadataProvider" xmlns="urn:m
ace:shibboleth:2.0:metadata" id="ucxn9a" metadataFile="/opt/shibboleth-idp/metad
ata/ucxn9a-single-agreement.xml" />
    <!--     Cisco CUCM Configuration               -->
   <metadata:MetadataProvider xsi:type="FilesystemMetadataProvider" xmlns="urn:m
ace:shibboleth:2.0:metadata" id="cucm9a" metadataFile="/opt/shibboleth-idp/metad
ata/cucm9a.cisco.net-single-agreement.xml" />
    <!--     Cisco CI Configuration               
   <metadata:MetadataProvider xsi:type="FilesystemMetadataProvider" xmlns="urn:m
ace:shibboleth:2.0:metadata" id="CI" metadataFile="/opt/shibboleth-idp/metadata/
idb-meta-ea7c1420-711d-4916-95f8-22de53230d1e-SP.xml" />
    </metadata:MetadataProvider>

SP 中繼資料來自 Shibboleth 檔案系統中的檔案,位於您為 Webex 組織上傳中繼資料的位置。

設定宣告屬性

1

在「資料連接器」區段中,指定擷取使用者的屬性的位置。

Active Directory,具有 MyLDAP 的 ID。

<resolver:DataConnector id="MyLDAP" xsi:type="dc:LDAPDirectory"
      ldapURL="ldap://ad0a.cisco.net:389"
      baseDN="cn=Users,dc=cisco,dc=net"
      principal="Administrator@cisco.net"
      principalCredential="ThePassword">
        <dc:FilterTemplate>
            <![CDATA[
                (sAMAccountName=$requestContext.principalName)
            ]]>
        </dc:FilterTemplate>
    </resolver:DataConnector>

2

在「屬性定義」區段中,保留 transientID 組態中已有的內容。

3

新增 SP 預期的額外屬性,並在屬性來源中定義它對應到的內容。

將屬性郵件(電子郵件地址屬性Active Directory)對應到 uid(Webex 中的用戶 ID)。

<resolver:AttributeDefinition id="mail-attr" xsi:type="ad:Simple" 
sourceAttributeID="mail">
        <resolver:Dependency ref="MyLDAP" />
        <resolver:AttributeEncoder xsi:type="enc:SAML2String" name="uid" />
     </resolver:AttributeDefinition>

4

在 attribute-filter.xml 檔案中定義要提供給每個 SP 協議的屬性。

向 Webex 提供對應至使用者電子郵件地址的 uid 屬性。

將屬性 uid 釋放到與 Webex 的 SP 協議中。

<!--  Release the attributes to cisco CI Cloud  -->
    <afp:AttributeFilterPolicy id="ReleaseToCI">
        <afp:PolicyRequirementRule xsi:type="basic:AttributeRequesterString" 
value="https://idbroker.webex.com/ea7c1420-711d-4916-95f8-22de53230d1e" />
        <afp:AttributeRule attributeID="transientId">
            <afp:PermitValueRule xsi:type="basic:ANY"/>
        </afp:AttributeRule>
        <afp:AttributeRule attributeID="mail-attr">
            <afp:PermitValueRule xsi:type="basic:ANY" />
        </afp:AttributeRule>
    </afp:AttributeFilterPolicy>

您在 attribute-resolver.xml 中建立的規則應該具有將 mail-attr 屬性釋放給與 Webex 相符的 EntityID 的原則。

5

在 /opt/shibboleth-idp/中繼資料中,從 Shibboleth 伺服器下載中繼資料檔案。 檔案名稱為 idp-metadata.xml。

匯入 IdP 中繼資料並在測試後啟用單一登入

匯出 Webex 中繼資料後,設定 IdP,然後將 IdP 中繼資料下載至本機系統,您便可以將中繼資料匯入至 Webex 組織(從 Control Hub)。

在開始之前

請勿從身分識別提供者 (IdP) 介面測試 SSO 整合。我們只支援由服務提供者發起(即由 SP 發起)的流程,因此您必須對此整合使用 Control Hub SSO 測試。

1

選擇一個:

  • 返回瀏覽器中的 Control Hub – 憑證選擇頁面,然後按 下一步。
  • 如果 Control Hub 不再在瀏覽器標籤中打開,請重新打開它。從 Control Hub 中的客戶視圖,前往 管理 > 安全 > 驗證,選擇 IdP,然後選擇 操作 > 導入元資料。
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 並按下一步。

此 SSO 設定不會在貴組織中生效,除非您先選擇圓鈕並啟動 SSO。

下一步

如果您想要將 Okta 以外的使用者佈建至 Webex 雲端,請使用將 Okta 使用者同步至 Cisco Webex Control Hub 中的程序。

如果您想要將使用者從 Entra ID 設定到 Webex 雲,請使用 將 Microsoft Entra ID 使用者同步到 Cisco Webex Control Hub 中的步驟。

您可以按照 抑制自動電子郵件 中的步驟來停用發送給組織中新 Webex 應用程式使用者的電子郵件。文件還包含將通訊傳送給您組織中的使用者的最佳做法。

本文是否有幫助?
本文是否有幫助?