没有浏览器的SAML 2.0

Question

我们说我的系统目前是这样的：

1. 单片Web应用程序：包含自己的帐户，并依赖客户端（基本上）使用HTTP BasicAuth登录。也就是说，用户名＆amp;密码被传递到服务器。

2. 胖客户端：登录到上面的应用程序，接收其后用于REST API调用的访问令牌。

基本上，我想将上述内容转换为这种系统：

1. SAML 2.0 IdP：身份记录系统

2. 相同的Web应用程序，减去身份验证责任

3. 胖客户端：不变。 ＆lt; - 硬性要求

所以，至关重要的是，我无法让胖客户端执行标准的SAML 2.0浏览器SSO重定向。有什么解决方案吗？从本质上讲，我喜欢与OAuth2 password_grant相同的功能，但在SAML 2.0世界中。

进行一些研究，我遇到了SAML Enhanced Client or Proxy，但支持似乎不稳定。令人沮丧的是，我在WebApp上以明文获得了darn凭证;是否有一些简单的方法可以使这项工作？

HTTP Artifact Binding可以解决这个问题吗？

Answer 1

注意：这个问题最好在 https://security.stackexchange.com/.

如果您无法更改胖客户端，则您无法使用 SAML 或任何形式的基于浏览器的单点登录 (SSO)。就这么简单。

此外，您期望用户将他们的 SSO 凭据输入胖客户端，然后通过 HTTP 基本身份验证发送它们并自动将它们输入表单的方法是不安全的，原因如下：

1. 用户的纯文本密码需要通过几个永远不会看到它的实例，并且它可能也将存储在胖客户端中。即使它是加密的（在传输中或静止时），这也不如密码仅作为散列存储在 IdP（以及用户的内存或密码管理器中）那样安全。
2. 期望用户在 IdP 登录表单以外的任何地方输入他们的 SSO 凭据会促进对凭据的危险使用，从而使用户更容易受到网络钓鱼攻击。

如果您计划将 IdP 用于 SSO 到多个客户端而不是这个传统胖客户端，您可以使用类似应用程序密码的内容：

1. 用户使用 SSO (SAML) 登录网络应用
2. 用户创建应用程序密码（并且还可以选择撤销它）
3. 然后将应用程序密码用于胖客户端。

“应用程序密码”可以是简单的唯一 ID（作为“用户名”输入）和随机生成的长字符串（作为“密码”发送）的组合。如果胖客户端可以存储这些凭据，那么这种方法会在一定程度上对用户友好，但不如真正的 SSO 安全。

从长远来看，请考虑更新胖客户端。