答: 要解决此错误，请执行以下操作:

1. 在 {IdP 名称}.properties 文件中，检索 osp.api.url 参数。

   该文件位于“{存储库文件夹}\sa\DomsInfo\osp\”目录中。

   例如，对于默认 alm IdP，打开“{存储库文件夹}\sa\DomsInfo\osp\alm.properties”文件以检索 osp.api.url 参数。

2. 运行以下命令以 ping 每个节点上的 osp.api.url:

   ping {osp.api.url}

3. 验证 ping 输出:

   • 如果 ping 命令无法获取 URL 并返回网络问题，则请求网络团队协助进一步诊断。

   • 如果网络团队未能提供可行的解决方案，请尝试以下解决方法:

     1. 在“{IdP 名称}.properties”文件中，将 osp.api.url 参数更改为服务器的本地地址。例如，osp.api.url= http\://localhost\:{http 端口号}/osp/a/{IdP 名称}

        要获取 http 端口号，请在“<安装目录>server\conf\jetty.xml”文件中，检查 <Set name="port"<property name="jetty.port" default=....></set> 行。

        Note: 确保在 jetty.xml 文件中启用 HTTP 通信，并且系统正在主动侦听此端口。

     2. 在每个节点上重新启动服务。

根本原因: 已在服务器上启用 forceAuthAtIDP 属性。

答: 在以下目录中的 authcfg.xml 文件中，将 forceAuthAtIDP 属性的值更新为 false:

• <安装目录>\webapps\osp\ospconf\WEB-INF\conf\current\{tenant name}\services\

• <安装目录>\osp\ospconf\WEB-INF\conf\current\{tenant name}\services\

例如，forceAuthAtIDP="${login.saml2.forceAuth:false}

答:

根本原因: 在 IdP 中注册了错误的 SP 元数据 URL，因此 IdP 无法识别从系统发送的 SAML 请求。

解决方案: 确保可以从 OpenText Application Quality Management 加载正确的 SP 元数据。并且，在验证 IdP 之前，应当在 IdP 中正确地将 OpenText Application Quality Management 注册为 SP。在 IdP 中注册 SP 元数据之后，当验证 IdP 时，您将被正确重定向到 IdP 登录页面。

答:

根本原因: SAML 响应断言未包含必需的 "IdentityKey" 断言。

解决方案: 如果 IdP 返回了 SAML 响应，则表示 IdP 与 OpenText Application Quality Management 之间的信任已成功建立。唯一的问题是无法验证 IdP 用户。OpenText Application Quality Management 用户和 IdP 用户是使用 IdentiyKey 值映射的。如果 IdP 不提供 SAML 响应的 IdentityKey 值，则 OpenText Application Quality Management 无法将 IdP 用户映射到任何 OpenText Application Quality Management 用户，因此验证失败。

要解决此问题，请在 IdP 中将 IdentityKey 映射为 SAML 属性，其具有唯一标识 IdP 用户的 IdP 属性。

答: 在 Web 浏览器中，输入 SP URL，如下所示: {ALM 主机:端口}/osp/a/alm/auth/app/。如果它将您重定向到 IdP 登录页面，并且在身份验证之后将您重定向回 SP 页面而没有出错，则表示 SP 已从 IdP 收到 SAML 响应: IdP 和 OpenText Application Quality Management 之间的信任已成功建立。

答:

根本原因: 使用了旧版本的 ALM 客户端启动器。

解决方案: 下载最新的 ALM 客户端启动器，以与 15.x SSO 解决方案一起使用。

https://marketplace.microfocus.com/appdelivery/content/alm-client-launcher

答: 如果您在*启用本地身份验证中将“启用本地身份验证”设为“是”，则系统在 OpenText Application Quality Management 端对本地用户进行身份验证，在 IdP 端对 IdP 用户进行身份验证。如果您是本地用户，则即使 IdP "alm" 未通过验证，OpenText Application Quality Management 仍允许您启用 SSO，因为在这种情况下，您仍然有机会作为本地用户登录来修复 IdP 配置，以便 IdP 用户可以登录。

答: 建议您启用本地身份验证，以便在启用 SSO 之后，本地用户仍可以登录来解决 SSO 配置问题。

答: 从 15.0.1 开始，启用 SSO 后，所有用户都将使用 SSO 身份验证或本地身份验证进行身份验证。

启用 SSO 后，本地帐户仍保留在系统中。要获得身份验证，每个本地帐户都应满足以下要求之一:

• 每个本地用户都映射到一个 IdP 用户。
• 每个本地用户配置为本地用户并启用本地身份验证。

答: 15.0.1 及更高版本支持本地身份验证。启用本地身份验证后，站点管理员可以通过将用户 IdP ID 指定为“本地”来将用户配置为本地用户: 此类本地用户可以直接登录。

答: 对项目数据没有影响。SSO 身份验证仅更改用户管理。

答: 切换到 SSO 模式不会修改现有用户的用户名。他们仍然可以像在非 SSO 模式下一样访问相同的资源。

他们只是映射到相应的 IdP 用户。USERS 表还有两列: US_IDENTITY_KEY 和 US_IDPID_NAME，用于保留每个用户的用户映射信息。

答: 当 15 在 SSO 模式下工作时，一些额外的 IdP 会话和 SP 会话将附加到 HTTP 请求的 Cookie 中，这使得请求标头的大小比在非 SSO 模式下运行系统时要大得多。如果用户的反向代理或系统将请求标头的大小限制为小于实际大小，则会发生此问题。

要解决此问题，请修改 Jetty 设置以增大请求标头的大小。推荐大小: 81920。要了解有关如何配置 Jetty 连接器的 "requestHeaderSize" 的详细信息，请参阅 Jetty 文档。

如果反向代理还限制了请求标头的大小，则让网络管理员修改大小。

答: 要手动修改 SSO 配置文件，请执行以下操作:

1. 在 {安装文件夹} 的 qcConfigFile.properties 文件中，将 "repositoryPath" 的值更新为新的存储库文件夹。

2. 在 {部署文件夹}/wrapper 的 wrapper.conf 文件中，将 "wrapper.java.additional.34" 的值更新为以下值:

   wrapper.java.additional.34=-Dalm.osp.framework.generic-properties-filename="{新存储库}/sa/DomsInfo/osp/basic.properties"

3. 在 {项目存储库文件夹} 的 basic.properties 文件中，将 "oauth-keystore.file" 的值更新为以下内容:

   oauth-keystore.file={新存储库}\\sa\\DomsInfo/osp/basic.pfx

4. 在 {项目存储库文件夹} 的 ospcfg.xml 文件中，将 name="propertiesFile" 的值更新为以下内容:

   <NamedValue value="{新存储库}\sa\DomsInfo/osp/alm.properties" name="propertiesFile"/>

5. 在 SSO 配置工具中，执行配置服务提供程序和配置标识提供程序。

答: 在 Chrome 或 Edge 中更改安全设置:

1. 在 Chrome 中输入 "chrome://flags/"，或者在 Edge 中输入 "edge://flags/"。
2. 搜索关键字 "SameSite by default cookies"。

3. 对于 Chrome: 将“Cookies without SameSite must be secure”和“SameSite by default cookies”选项设置为“Disabled”。

   对于 Edge: 将“SameSite by default cookies”和“Schemeful Same-Site”选项设置为“Disabled”。