单点登录和 Control Hub

单点登录 (SSO) 是一种会话或用户验证的流程，允许用户通过提供凭证来访问一个或多个应用程序。此流程能够为用户已获得授权的所有应用程序验证用户。这样用户在特定会话期间切换应用程序时，不会再看到额外提示。

安全断言标记语言 (SAML 2.0) 联合协议用于提供 Webex 云与您的身份提供商 (IdP) 之间的 SSO 验证。

档案

Webex 应用程序仅支持 Web 浏览器 SSO 档案。在 Web 浏览器 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 中使用而配置。

单点注销

Webex 应用程序支持单点注销档案。在 Webex 应用程序中，当用户注销应用程序时，系统会使用 SAML 单点注销协议结束会话并与您的 IdP 确认该注销操作。请确保您的 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 或 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。（请参阅配置 Webex 的单点登录了解站点管理中 SSO 集成的更多信息。）

此处的集成步骤针对的是在以 Tomcat 7 作为 Web 服务器的 CentOS 7 中运行的 Shibboleth 2.4.5。

准备工作

对于 SSO 和 Control Hub，IdP 必须遵循 SAML 2.0 规范。此外，IdP 必须按以下方式进行配置：

下载 Webex 元数据到本地系统

1

从https://admin.webex.com中的客户视图，转至管理 > 组织设置，然后滚动至身份验证，然后打开单点登录设置以启动设置向导。

2

选择组织的证书类型：

  • 由Cisco自行签名—我们建议您选择此选项。我们在证书上签名，您只需每五年续订一次。
  • 由公共证书颁发机构签名—更安全，但您需要经常更新元数据（除非IdP供应商支持信任锚）。

信任锚是充当验证数字签名证书的认证中心的公共密钥。有关更多信息，请参阅 IdP 文档。

3

下载元数据文件。

Webex元数据文件名是 idb-meta--SP.xml。

在 Shibboleth 文件中配置授权

安装 Shibboleth 后，将为您提供含有示例的配置文件。

1

转至 /opt/shibboleth-idp/conf 目录以访问这些示例文件。

2

决定要使用的授权方法，例如“将 LDAP 绑定到 Active Directory”。

3

按如下所示编辑 handler.xml 文件：

取消注释

  <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：未指定</ph：AuthenticationMethod> </ph：LoginHandler>
4

填写 Active Directory 的详细信息以允许验证。将该配置信息添加到 login.config 文件。

ShibUserPassAuth { edu.vt.middleware.ldap.jaas.LdapLoginModule需要ldapUrl="ldap：//ad0a.cisco.net：389" ssl="false" tls="false" baseDn="cn=Users，dc=cisco，dc=net" subtreeSearch="true" userFilter="sAMAccountName={0}" bindDn="cn=管理员，cn=Users，dc=cisco，dc=net" bindCredential="ThePassword"； }；

配置 SAML 断言的 Shibboleth 服务商组件

1

将从 Webex SP 下载的文件添加到 /opt/shibboleth-idp/metadata 目录。

2

编辑 relying-party.xml 文件；在DefaultRelyingParty标签之后，添加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"/>

标识必须使用 Webex 元数据文件的 EntityID 值。请将示例中的 ID 替换为组织的 EntityID。

3

在 metadata:MetadataProvider 标记内部，添加文件的位置：

  <metadata：MetadataProvider id="IdPMD" xsi：type="metadata：FilesystemMetadataProvider" metadataFile="/opt/shibboleth-idp/metadata/idp-metadata.xml" maxRefreshDelay="P1D" />  <metadata：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配置 <metadata：MetadataProvider xsi：type="FilesystemMetadataProvider" xmlns="urn：m ace：shibboleth：2.0：metadata" id="CI" metadataFile="/opt/shibboleth-idp/metadata/ idb-meta-ea7c1420- d-4916-95f8-22de53230d1e-SP.xml" />

SP 元数据来自 Shibboleth 文件系统中的文件，该文件保存在您将 Webex 组织元数据上传到的位置。

配置断言属性

1

在 Data Connector 节中，指定从中检索用户属性的位置。

id 为 MyLDAP 的 Active Directory。

<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

在 Attribute Definition 节中，保留 transientID 配置的现有值。

3

添加 SP 预期的额外属性，并定义它将映射到属性源中的哪个属性。

将属性邮件（Active Directory中的电子邮件地址属性）映射到uid（Webex中的UserID）。

<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 属性。

使用 Webex 将属性 uid 发放给 SP 协议。

 <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：PermitValueRule xsi：type="basic：ANY"/> </afp：AttributeRule>

您在 attribute-resolver.xml 中创建的规则应该有一个策略，将邮件攻击属性发布到与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

选择一种：

  • 返回浏览器中的Control Hub –证书选择页面，然后单击下一步。
  • 如果浏览器标签页中不再打开Control Hub，请从 https://admin.webex.com 中的客户视图，转至 管理 > 组织设置，滚动至验证，然后选择操作 > 导入元数据。
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 中的过程。

如果您要从 Azure AD 中将用户预先配置到 Webex 云，请使用将 Azure Active Directory 用户同步到 Cisco Webex Control Hub 中的过程。

您可以按照抑制自动电子邮件 中的步骤禁用发送到组织中的新Webex应用程序用户的电子邮件。文档中还包含向组织中用户发送通信的最佳实践。