在SAML中，服务提供者和实际应用程序之间的通信是如何发生的？

Question

据我所知，国内流离失所者与SP之间的沟通在标准中有很好的定义。我想知道在独立SP和实际应用程序之间实现自定义通信的方法是什么。

我认为标准的方式是存在的，而不是重新发明我自己的车轮。但就连spring-saml security也只谈到“自定义机制”，并没有说明它是什么。

有人能指点我正确的方向吗？我已经搜索过了，但我感到惊讶的是，它没有写任何博客，教程等。甚至在Shibboleth/Gluu文档中也没有，这部分不知何故被忽略了。

任何帮助都将不胜感激。

Answer 1

问题实质上归结为“两个部署在可信网络中的应用程序如何安全地相互通信，以便交换有关用户的安全信息”。SAML解决了在不受信任的网络上通信的应用程序所面临的同样问题，并且由于身份验证点(SP)和应用程序都在同一实体的控制下(例如，更容易使用系统加密)，使得SAML变得更容易。SP原则上可以使用前端通道(=通过web浏览器)或后端通道(=通过网络相互直接通信)与应用程序进行通信。

有不同的方式来执行通信(使用一个、另一个或两个通道)，大多数可以使用一些可用的安全产品来实现。以下是一些想法：

-- SP和应用程序共享同一个域(=用户的web浏览器在共享cookies的URL上访问它们)

• 您可以配置您的SP来存储cookie --这是一条信息，包括UID和经过身份验证的用户的过期，可以使用SP和应用程序都知道的共享秘密对cookie进行加密。这是OpenAM或Wildfly使用的共享域加密cookie所使用的方法。
• 这种方法的另一种方法是将有关经过身份验证的用户的信息从SP发送到应用程序，例如，作为一个加密的HTTP参数-- SAML所做的类似方法，只是更基本的方法。
• 可以通过使用另一个安全共享存储来增强相同的方法--例如数据库和只发送对记录的引用(例如，唯一的秘密会话ID)。

SP可用作应用程序的HTTP

• 在这种情况下，您可以将身份验证信息作为HTTP头传递给应用程序，您必须确保通过SP访问应用程序是唯一的方式。只有当SP是负载均衡器(例如Apache / Nginx插件)的一部分时，这才是实用的。

SP和应用程序可以使用标准的身份验证机制来传递身份验证数据。

• 您可以使用例如Kerberos (无论如何都是基于共享秘密加密)或OAuth。

每个选项都可能有不同的攻击向量和可能的漏洞。

我的观点是，将SAML功能直接添加到应用程序中，使用带有SAML支持的HTTP或处理SP与应用程序(例如OpenAM)之间的最后一英里身份验证的标准产品是最好的方法。实现自定义安全机制似乎很容易，但是有很大的空间来犯错误，从而使整个解决方案容易受到攻击。