使用SAML承载令牌来验证用户后端服务是个坏主意吗？

Question

假设我有一个想要从后端服务获取一些数据的前端应用程序.(我这样做.)服务需要验证最终用户是否经过身份验证,是否有权使用该服务,并可能根据用户的权限过滤返回的数据.就我而言,前端应用程序和后端服务都依赖Azure ACS进行身份验证.

理想情况下,前端希望代表经过身份验证的用户执行操作,这听起来非常适合使用ActAs令牌(如WS-Trust中所指定).然而,事实证明ACS目前不支持ActAs.

解决方法可能是使用实际的承载令牌(前端应用程序中的引导令牌)对后端服务进行身份验证.做起来并不难,但出于某种原因会不是一个坏主意？

Answer 1

从您的前端应用程序,您当然可以通过按原样发送令牌或从中发送属性来传递最终用户的身份数据.两者都有问题.对于前者,如果它也被加密,前端和后端将必须共享解密它所需的私钥; 他们还必须分享受众限制等,以便后端考虑对其有效的令牌.换句话说,前端和后端将是一个依赖方,而不是两个.可能不是问题,但请注意.在后一种情况下,您最终会以固有的方式发送用户数据,这会增加整合和维护成本.在这两种情况下,您都可以使用其他类型的凭证对前端应用程序进行身份验证,例如,在传输级别使用的证书,从而在它们之间形成可信子系统.

我建议你考虑的一件事是OAuth 2.从这篇博文中,我觉得ACS支持它(虽然我没有任何第一手经验).关于OAuth 2的真正精彩之处在于它将代理授权,并且与WS-Trust中的ActAs一样复杂.最终结果是相同的,即后端服务将具有关于呼叫服务和最终用户的信息,但是将其设置为无与伦比的努力量.令牌仍然是持有者令牌,但您可以通过使用SSL来缓解这种情况.除了SSL之外,您还可以采取一些额外的措施,但最好的IMO,如果微软在ACS中做了一些事情,就像谷歌已经为他们的服务帐户使用访问令牌一样,这些服务帐户使用链接到PKI的非对称密钥.(顺便说一下,据我所知,微软可能已经做过类似的事了;如果有的话,你已经确定了.)

无论如何,HTH!