SAML 中的服务提供商和实际应用程序之间如何/应该如何进行通信?
我了解 IDP 和 SP 之间的通信在标准中有明确定义.我想知道有什么方法可以在独立 SP 和实际应用程序之间进行自定义通信.
I understand that the communication between IDP and SP is well defined in standard. I'm wondering what are the ways to make the custom communication happen between standalone SP and the actual application.
我假设存在标准方法，而无需自己重新发明轮子.但是即使spring-saml security只谈自定义机制"，也没有说它是什么.
I assume the standard ways exists, without reinventing the wheel my self. But even spring-saml security only talks about "custom mechanism" doesn't say what it is.
有人能指出我正确的方向吗?我已经搜索过了，但令我惊讶的是，它没有写在博客、教程等任何地方.即使在 Shibboleth/Gluu 文档中，那部分也不知何故被搁置了.
Can someone point to me the right direction? I've searched but I'm surprised that it's not written anywhere blogs, tutorials etc. Not even in Shibboleth/Gluu documentation, that part is somehow left alone.
任何帮助将不胜感激.
问题本质上归结为部署在受信任网络中的两个应用程序如何安全地相互通信以交换有关用户的安全信息.这与 SAML 为通过不受信任的网络通信的应用程序解决的问题相同，并且由于身份验证点 (SP) 和应用程序都在同一实体的控制之下，因此变得更容易了 = 例如更容易使用对称密码学.原则上，SP 可以使用前端通道(= 通过网络浏览器)或后端通道(= 通过网络相互之间直接通信)与应用程序通信.
The problem essentially boils down to "how can two applications deployed in a trusted network securely communicate with each other in order to exchange security information about a user". It's the same problem SAML solves for applications communicating over untrusted network and it's made easier by the fact that both the authentication point (SP) and the application are under control of the same entity = it's e.g. easier to use symetric cryptography. The SP can in principle communicate with the app using either front-end channel (= through web browser), or back-end channel (= directly between each other over network).
执行通信的方式有多种(使用一种、另一种或两种渠道)，大多数可以使用一些可用的安全产品来实现.以下是一些想法:
There are different ways to perform the communication (using one, the other, or both channels), most can be implemented using some of the available security products. Here are some ideas:
SP 和应用程序共享同一个域(= 用户的网络浏览器通过共享 cookie 的 URL 访问它们)
- 您可以配置您的 SP 以存储 cookie - 一条信息，例如UID 和经过身份验证的用户的到期时间，可以使用 SP 和应用程序都知道的共享机密对 cookie 进行加密.这是使用的方法，例如由 OpenAM 或具有共享域加密 cookie 的 Wildfly 提供.
- 这种方法的另一种选择是将有关经过身份验证的用户的信息从 SP 发送到应用程序，例如作为加密的 HTTP POST 参数 - 与 SAML 类似的方法，只是更基本.
- 可以通过使用另一个安全共享存储来增强相同的方法 - 例如数据库并仅发送对记录的引用(例如唯一的秘密会话 ID)
SP 可用作应用程序的 HTTP 代理
- 在这种情况下，您可以将身份验证信息作为 HTTP 标头传递给应用程序，您必须确保通过 SP 是访问应用程序的唯一途径.这仅在 SP 是例如的一部分时才实用.负载平衡器(例如 Apache/Nginx 插件).
SP 和应用程序可以使用标准的身份验证机制来传递身份验证数据
- 你可以使用例如Kerberos(无论如何都基于共享秘密加密)或 OAuth
每个选项可能有不同的攻击媒介和可能的漏洞.
Each of the option might have different attack vectors and possible vulnerabilities.
我的观点是，将 SAML 功能直接添加到应用程序、使用支持 SAML 的 HTTP 代理或处理 SP 和应用程序之间最后一英里身份验证的标准产品(例如 OpenAM)是最好的方法.实施自定义安全机制似乎很容易，但犯错的空间很大，这会使整个解决方案容易受到攻击.
My opinion is that adding SAML functionality directly into the application, using the HTTP proxy with SAML support, or a standard product which handles the last mile authentication between SP and the application (e.g. OpenAM) is the best way to go. Implementing custom security mechanism might seem easy, but there's a lot of room for making a mistake which leaves the whole solution vulnerable.