does/should SAML 中的服务提供商和实际应用程序之间如何进行通信？
How does/should the communication happen between Service Provider and Actual application in SAML?
我了解 IDP 和 SP 之间的通信在标准中有明确定义。我想知道在独立 SP 和实际应用程序之间进行自定义通信的方法是什么。
我假设存在标准方法，而无需自己重新发明轮子。但是连spring-saml security也只说了"custom mechanism"并没有说是什么
有人能给我指出正确的方向吗？我已经搜索过了，但令我惊讶的是它没有写在博客、教程等任何地方。甚至在 Shibboleth/Gluu 文档中也没有，那部分不知何故被单独留下了。
如有任何帮助，我们将不胜感激。
问题本质上归结为"how can two applications deployed in a trusted network securely communicate with each other in order to exchange security information about a user"。这与 SAML 为通过不受信任的网络进行通信的应用程序解决的问题相同，并且由于身份验证点 (SP) 和应用程序都在同一实体的控制下 = 例如，它变得更容易。更容易使用对称加密。 SP 原则上可以使用 front-end 通道（= 通过网络浏览器）或 back-end 通道（= 直接通过网络在彼此之间）与应用程序通信。
执行通信的方式有很多种（使用一个、另一个或两个通道），大多数都可以使用一些可用的安全产品来实现。以下是一些想法：
SP 和应用程序共享同一个域（= 用户的 Web 浏览器在共享 cookie 的 URL 上访问它们）
- 您可以将您的 SP 配置为存储 cookie - 一条信息，包括例如经过身份验证的用户的 UID 和过期时间，cookie 可以使用 SP 和应用程序都知道的共享秘密进行加密。这是使用的方法，例如通过 OpenAM，或 Wildfly 使用共享域加密 cookie。
- 此方法的另一种方法是将有关经过身份验证的用户的信息从 SP 发送到应用程序，例如作为加密的 HTTP POST 参数 - 与 SAML 类似的方法，只是更基本。
- 可以通过使用另一个安全共享存储来增强相同的方法 - 例如一个数据库并仅发送对记录的引用（例如，唯一的秘密 session ID）
SP 可用作应用程序的 HTTP 代理
- 在这种情况下，您可以将身份验证信息作为 HTTP header 传递给应用程序，您必须确保通过 SP 是访问应用程序的唯一途径。这仅在 SP 是例如的一部分时才实用。负载均衡器（例如 Apache / Nginx 插件）。
SP 和应用程序可以使用标准的身份验证机制来传递身份验证数据
- 你可以使用例如Kerberos（无论如何都基于 shared-secret 加密）或 OAuth
每个选项可能有不同的攻击向量和可能的漏洞。
我的观点是，将 SAML 功能直接添加到应用程序中，使用支持 SAML 的 HTTP 代理，或者处理 SP 和应用程序之间最后一英里身份验证的标准产品（例如 OpenAM）是最好的方法.实施自定义安全机制似乎很容易，但犯错误的空间很大，这会使整个解决方案容易受到攻击。
我了解 IDP 和 SP 之间的通信在标准中有明确定义。我想知道在独立 SP 和实际应用程序之间进行自定义通信的方法是什么。
我假设存在标准方法，而无需自己重新发明轮子。但是连spring-saml security也只说了"custom mechanism"并没有说是什么
有人能给我指出正确的方向吗？我已经搜索过了，但令我惊讶的是它没有写在博客、教程等任何地方。甚至在 Shibboleth/Gluu 文档中也没有，那部分不知何故被单独留下了。
如有任何帮助，我们将不胜感激。
问题本质上归结为"how can two applications deployed in a trusted network securely communicate with each other in order to exchange security information about a user"。这与 SAML 为通过不受信任的网络进行通信的应用程序解决的问题相同，并且由于身份验证点 (SP) 和应用程序都在同一实体的控制下 = 例如，它变得更容易。更容易使用对称加密。 SP 原则上可以使用 front-end 通道（= 通过网络浏览器）或 back-end 通道（= 直接通过网络在彼此之间）与应用程序通信。
执行通信的方式有很多种（使用一个、另一个或两个通道），大多数都可以使用一些可用的安全产品来实现。以下是一些想法：
SP 和应用程序共享同一个域（= 用户的 Web 浏览器在共享 cookie 的 URL 上访问它们）
- 您可以将您的 SP 配置为存储 cookie - 一条信息，包括例如经过身份验证的用户的 UID 和过期时间，cookie 可以使用 SP 和应用程序都知道的共享秘密进行加密。这是使用的方法，例如通过 OpenAM，或 Wildfly 使用共享域加密 cookie。
- 此方法的另一种方法是将有关经过身份验证的用户的信息从 SP 发送到应用程序，例如作为加密的 HTTP POST 参数 - 与 SAML 类似的方法，只是更基本。
- 可以通过使用另一个安全共享存储来增强相同的方法 - 例如一个数据库并仅发送对记录的引用（例如，唯一的秘密 session ID）
SP 可用作应用程序的 HTTP 代理
- 在这种情况下，您可以将身份验证信息作为 HTTP header 传递给应用程序，您必须确保通过 SP 是访问应用程序的唯一途径。这仅在 SP 是例如的一部分时才实用。负载均衡器（例如 Apache / Nginx 插件）。
SP 和应用程序可以使用标准的身份验证机制来传递身份验证数据
- 你可以使用例如Kerberos（无论如何都基于 shared-secret 加密）或 OAuth
每个选项可能有不同的攻击向量和可能的漏洞。
我的观点是，将 SAML 功能直接添加到应用程序中，使用支持 SAML 的 HTTP 代理，或者处理 SP 和应用程序之间最后一英里身份验证的标准产品（例如 OpenAM）是最好的方法.实施自定义安全机制似乎很容易，但犯错误的空间很大，这会使整个解决方案容易受到攻击。