SAML 和后端 REST 服务身份验证
我有一个这样的应用程序工作流程
I have an application workflow like this
(A) 用户代理(浏览器)<-----> (B) 应用服务器 <------> (C) REST 服务
(A) User-Agent (browser) <-----> (B) App Server <------> (C) REST service
假设应用服务器 (B) 是 SAML 服务提供商，并且 user@domain 使用 Web 浏览器 SSO 配置文件从浏览器 (A) 到应用服务器 (B) 进行身份验证.
Suppose the app server (B) is a SAML service provider and user@domain authenticates from the browser (A) to the app server (B) using the Web Browser SSO profile.
在 (B) 上运行的应用程序如何以 user@domain.com身份向 REST 服务 (C) 进行身份验证?(假设 B 和 C 都是同一 IdP 上的 SAML SP.)
How can an application running on (B) authenticate to a REST service (C) as user@domain.com? (Assuming B and C are both SAML SP's on the same IdP.)
如果浏览器只是对 B 和 C 进行 AJAX 调用，那就很简单了.但是如果直接从应用程序调用 REST 服务，你会怎么做?
If the browser were just making AJAX calls to both B and C, it would be straightforward. But if the REST service is invoked directly from the application, what do you do?
我遇到的问题:如果应用程序本身不是 SAML SP，而是集成一个(例如，使用 Shibboleth SP 和 REMOTE_USER 标头)，您的应用程序可能永远不会看到 SAML 断言.您知道用户已登录并根据 IdP 进行身份验证，但无法获得 SAML 断言以移交给后端服务.
What I'm struggling with: If the application itself is not the SAML SP, but integrated with one (say, using Shibboleth SP and the REMOTE_USER header) your application may never see a SAML assertion. You know the user is logged in and authenticated against an IdP but have no way to get a SAML assertion to hand off to the backend service.
有什么解决办法还是我运气不好?
Is there a solution or am I out of luck?
既然你说应用服务器 B 和 REST 服务 C 都是 SAML SPSAML IdP，您必须已经有一种机制，允许 Web 客户端通过 SAML Web 浏览器 SSO 配置文件，对吗?当这个登录工作流"完成后，API 客户端有一个 auth 令牌，代表user@domain.com 被 IdP X 认证使用 SP C"，并且可以用于在一段时间内对 C 的调用进行身份验证(直到身份验证令牌过期).
Since you're saying App Server B and REST service C are both SAML SPs with the same SAML IdP, you must already have a mechanism in place which allows a web client to authenticate against C directly (independently of B) via the SAML Web Browser SSO Profile, right? And when this "login workflow" has been completed, the API client has an auth token which represents the fact that "user@domain.com is authenticated by IdP X to use SP C", and can be used to authenticate calls to C for some period of time (until the auth token expires).
但是 B 和 C 是独立的服务.并且如果他们有不同的 SAML 服务提供商实体 ID 注册到相同的 IdP X，那么 IdP X 将不认为这些陈述是等效的:
But B and C are separate services. And if they have different SAML Service Provider entityIDs registered with the same IdP X, then IdP X will not consider these statements to be equivalent:
- user@domain.com 由 IdP X 验证以使用 SP C
- user@domain.com 由 IdP X 验证以使用 SP B
因此，服务 B 应该没有办法使用代表上述语句 2 的身份验证令牌(它可以从自己的 SAML SSO 登录工作流中获取)来获取持有代表上述语句 1 的身份验证令牌(只能来自 C 的 SAML SSO 登录工作流).服务 B 也不应该通过"API 客户端到服务 C SAML SSO 登录工作流，而不会失去对工作流的控制.
So there should be no way for service B to use an auth token representing statement 2 above (which it may get from its own SAML SSO login workflow) to get hold of an auth token representing statement 1 above (which can only come from the SAML SSO login workflow for C). Nor should it be possible for service B to "pass through" the API client to the service C SAML SSO login workflow without then losing control over the workflow.
另一方面，如果 B 和 C 具有向 IdP 注册的相同 SAML 服务提供商实体 ID，则上述语句 1 是逻辑和安全方面的相当于上面的陈述 2.在这种情况下，最直接的解决方案是让服务 B 和 C 使用相同的身份验证令牌系统.无论如何，这确实是唯一可行的方法，因为如果 B 和 C 具有相同的 SAML SP entityID，那么 IdP 将只为两个配置一个 ACS URLem>B 和 C，这意味着再次就 IdP 而言，它们实际上是同一个 SAML SP.
On the other hand, if B and C have the same SAML Service Provider entityID registered with the IdP, then statement 1 above is logically-and-security-wise equivalent to statement 2 above. In this case, the most straightforward solution would be for services B and C to use the same auth token system. Which is really the only way this could work anyway, since if B and C have the same SAML SP entityID then the IdP would have only a single ACS URL configured for both B and C, which means that again as far as the IdP is concerned they are really one and the same SAML SP.