我有一个像这样的应用程序工作流程
（A）用户代理（浏览器）＆lt; -----＆gt; （B）App Server＆lt; ------＆gt; （C）REST服务
假设应用服务器（B）是SAML服务提供商，而user @ domain使用Web浏览器SSO配置文件从浏览器（A）到应用服务器（B）进行身份验证。
运行在（B）上的应用程序如何通过user@domain.com 向REST服务（C）进行身份验证？ （假设B和C都是同一个IdP上的SAML SP。）
如果浏览器只是对B和C进行AJAX调用，那么它会很简单。但是如果直接从应用程序调用REST服务，你会怎么做？
我正在努力解决的问题：如果应用程序本身不是SAML SP，而是集成（例如，使用Shibboleth SP和REMOTE_USER标头），您的应用程序可能永远不会看到SAML断言。您知道用户已登录并根据IdP进行身份验证，但无法获取SAML断言以切换到后端服务。
有解决方案还是我运气不好？
答案 0 :(得分：1)
是的，没有什么能阻止您的App Server（B）充当服务提供商，接受来自A的传入断言并充当身份提供者，发出自己的SAML票证，然后转发给C。
如果您无法访问原始断言，则必须在B中发出新断言。如果您确实可以访问原始断言，则可以将其转发到C，如果C配置为忽略受众限制将断言限制为仅对B有效。
答案 1 :(得分：0)
由于您说App Server B 且REST服务 C 都是具有相同SAML IdP的SAML SP，因此您必须已有适当的机制允许Web客户端通过SAML Web Browser SSO Profile直接（独立于 B ）对 C 进行身份验证，对吗？当这个“登录工作流程”完成后，API客户端有一个auth令牌，表示“user@domain.com由IdP X验证使用SP C ”，并且可以用于验证对 C 的调用一段时间（直到授权令牌过期）。
但 B 和 C 是单独的服务。 如果他们有相同的IdP X注册的不同SAML服务提供商实体ID，那么IdP X将不认为这些陈述是等效的：
因此服务 B 应该无法使用代表上述语句2的身份验证令牌（可以从其自己的SAML SSO登录工作流程中获取）获取保持代表上述语句1的身份验证令牌（只能来自 C 的SAML SSO登录工作流程）。服务 B 也不可能将API客户端“传递”到服务 C SAML SSO登录工作流程，而不会失去对工作流程的控制权。
另一方面，如果 B 和 C 具有向IdP注册的相同SAML服务提供商实体ID，则上面的语句1在逻辑上和安全方面是明智的相当于上面的陈述2。在这种情况下，最直接的解决方案是服务 B 和 C 使用相同的身份验证令牌系统。这实际上是唯一可行的方法，因为如果 B 和 C 具有相同的SAML SP entityID，那么IdP将只为两个配置一个ACS URL < em> B 和 C ，这意味着就IdP而言，它们实际上是同一个SAML SP。