single-sign-on - 在 PingFederate 中导出/导入元数据

标签 single-sign-on pingfederate

我使用 PingFederate 充当 IdP 服务器和 SP 服务器。之后我为每个组件提供了 OpenToken 适配器。我已使用新创建的适配器在服务器配置设置下创建了IdP-to-SP适配器映射

转到SP CONNECTIONS > IdP Configuration部分,我创建了一个新连接。

之后,在服务器配置 > 管理功能 > 元数据导出中,我导出了新创建的 SP 连接。

现在,当我尝试使用 SP 配置 > IDP 连接 > 创建新 中的元数据时,导出功能工作正常,但本应从 .xml 文件加载的数据并未发生.

这是我的metadata.xml 文件的样子:

<?xml version="1.0"?>

-<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" entityID="localhost:default:entityId" cacheDuration="PT1440M" ID="Kuvm5eRQl_BYQ27ZVtV4OCcHb.1">


-<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">


-<ds:SignedInfo>

<ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>

<ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>


-<ds:Reference URI="#Kuvm5eRQl_BYQ27ZVtV4OCcHb.1">


-<ds:Transforms>

<ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>

<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>

</ds:Transforms>

<ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>

<ds:DigestValue>wn/+y44KVd1I0RfdGVnq7NGW9wc=</ds:DigestValue>

</ds:Reference>

</ds:SignedInfo>

<ds:SignatureValue> pX78c96Eq//dZQIRIzEFquvcnzlnrOh4Nnfdfc5BNgdpokdnBEE91Cr20YatuQqHg61XssjVoyLi 4HfzhAqf85ni+p/NyEi8iQx86W3JptmawzkA1nFY8+JD6m/WIblipHh/1l63tF1N0akoNwhbDhky jmiBpPgPc8FxJAOPE7k= </ds:SignatureValue>


-<ds:KeyInfo>


-<ds:X509Data>

<ds:X509Certificate> MIICRzCCAbCgAwIBAgIGAUIOacSJMA0GCSqGSIb3DQEBBQUAMGYxCzAJBgNVBAYTAlVTMQswCQYD VQQIEwJDTzEPMA0GA1UEBxMGRGVudmVyMQwwCgYDVQQKEwNEZXYxDTALBgNVBAsTBFBpbmcxHDAa BgNVBAMTE0NvbmZpZyBTaWduaW5nIENlcnQwIBcNMTMxMDMxMTIwODAxWhgPMjExMzEwMDcxMjA4 MDFaMGYxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJDTzEPMA0GA1UEBxMGRGVudmVyMQwwCgYDVQQK EwNEZXYxDTALBgNVBAsTBFBpbmcxHDAaBgNVBAMTE0NvbmZpZyBTaWduaW5nIENlcnQwgZ8wDQYJ KoZIhvcNAQEBBQADgY0AMIGJAoGBALD4NA4uYzAxWBih6BXwyPSFlw94dolpigT1FrTeT/SGAlAg teWp2Fy2LB0mVm2tSmRyYOi85c8M9jRjaB8SB688C1Q6TqNUvhfhje46GqDuUPxguCXHZsNS9XwM trWwGzm7IenVL1WJ4LHPJI0OYt8qH7nZ6FFUDW0fbuIMMLo/AgMBAAEwDQYJKoZIhvcNAQEFBQAD gYEAkzykqYJasH8Tms2QlFa5HNWL1q8dpbp6ksEOi4E1mL1SZGs7iWM8ltYfMro1mGF/SWWxfStJ EEWiA01AigehJn2w5VPysYZxODBO1jYzRSyZo8hU8ioMcSZTpwgokzUZmMlwDhrbzDQmdh//sbri 1QB59uqG0CwU2/AJV3KU2KM= </ds:X509Certificate>

</ds:X509Data>


-<ds:KeyValue>


-<ds:RSAKeyValue>

<ds:Modulus> sPg0Di5jMDFYGKHoFfDI9IWXD3h2iWmKBPUWtN5P9IYCUCC15anYXLYsHSZWba1KZHJg6Lzlzwz2 NGNoHxIHrzwLVDpOo1S+F+GN7joaoO5Q/GC4Jcdmw1L1fAy2tbAbObsh6dUvVYngsc8kjQ5i3yof udnoUVQNbR9u4gwwuj8= </ds:Modulus>

<ds:Exponent>AQAB</ds:Exponent>

</ds:RSAKeyValue>

</ds:KeyValue>

</ds:KeyInfo>

</ds:Signature>


-<md:IDPSSODescriptor WantAuthnRequestsSigned="false" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">


-<md:KeyDescriptor use="signing">


-<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">


-<ds:X509Data>

<ds:X509Certificate>MIICRzCCAbCgAwIBAgIGAUIOacSJMA0GCSqGSIb3DQEBBQUAMGYxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJDTzEPMA0GA1UEBxMGRGVudmVyMQwwCgYDVQQKEwNEZXYxDTALBgNVBAsTBFBpbmcxHDAaBgNVBAMTE0NvbmZpZyBTaWduaW5nIENlcnQwIBcNMTMxMDMxMTIwODAxWhgPMjExMzEwMDcxMjA4MDFaMGYxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJDTzEPMA0GA1UEBxMGRGVudmVyMQwwCgYDVQQKEwNEZXYxDTALBgNVBAsTBFBpbmcxHDAaBgNVBAMTE0NvbmZpZyBTaWduaW5nIENlcnQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALD4NA4uYzAxWBih6BXwyPSFlw94dolpigT1FrTeT/SGAlAgteWp2Fy2LB0mVm2tSmRyYOi85c8M9jRjaB8SB688C1Q6TqNUvhfhje46GqDuUPxguCXHZsNS9XwMtrWwGzm7IenVL1WJ4LHPJI0OYt8qH7nZ6FFUDW0fbuIMMLo/AgMBAAEwDQYJKoZIhvcNAQEFBQADgYEAkzykqYJasH8Tms2QlFa5HNWL1q8dpbp6ksEOi4E1mL1SZGs7iWM8ltYfMro1mGF/SWWxfStJEEWiA01AigehJn2w5VPysYZxODBO1jYzRSyZo8hU8ioMcSZTpwgokzUZmMlwDhrbzDQmdh//sbri1QB59uqG0CwU2/AJV3KU2KM=</ds:X509Certificate>

</ds:X509Data>

</ds:KeyInfo>

</md:KeyDescriptor>

<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified</md:NameIDFormat>

<md:SingleSignOnService Location="https://localhost:9031/idp/SSO.saml2" Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"/>

</md:IDPSSODescriptor>

<md:ContactPerson contactType="administrative"/>

</md:EntityDescriptor>

.xml 文件中的 entityId 属性指向 localhost:default:entityId 但它不是应该是 SP连接的合作伙伴实体ID。看起来它正在从全局服务器设置的服务器设置>联邦信息中提取值。 问题:

  1. entityId 是否应该从联邦信息或 SP 中提取 连接?
  2. 如何映射 SP 连接和 IdP 连接?
  3. metadata.xml 文件填充哪些字段?

引用:

Training Video

最佳答案

默认情况下,您的entityId 在“服务器设置”>“联合信息”下进行全局设置。这就是当您导出通用或连接级元数据以与合作伙伴共享时您将看到的内容。您在实际 IDP 或 SP 连接中输入的值是您的合作伙伴的实体 ID。在这种情况下,由于您同时充当 IDP 和 SP,因此 IDP 和 SP 连接中的entityId 值将相同 (localhost:default:entityId),这可能会造成混淆。

如果需要,您可以利用虚拟服务器 ID 来覆盖服务器级默认实体 ID,这将覆盖给定连接的颁发者值。

您可以在PingFedate Admin Guide中找到有关这些字段的更多信息。

--伊恩

关于single-sign-on - 在 PingFederate 中导出/导入元数据,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/23728792/

相关文章:

java - 在 Java 中没有 cookie 的单点登录

authentication - 通过 PingFederate 对启用单点登录的服务进行脚本访问

oauth-2.0 - 如何将 "accounts"的概念添加到Keycloak中?

node.js - 使用 Tomcat 和 NodeJS 进行单点登录

saml - PingFederate 和 ADFS 是否支持 ECP(增强型客户端和代理)配置文件?

pingfederate - 为什么 PingFederate IdP 连接需要 SP 适配器?

single-sign-on - PingFederate 单次注销 - 它是如何工作的?

java - 在 Java 中使用 SAML2 进行 SSO 身份验证以及如何使用 HtmlUnit 执行 JavaScript

single-sign-on - Databricks SSO 身份验证失败 |谷歌国内流离失所者