【问题标题】:What is a good way of forwarding credentials within a web environment?在 Web 环境中转发凭据的好方法是什么?
【发布时间】:2015-03-16 02:38:21
【问题描述】:

给定以下配置:

  • 网络客户端 = 普通的现代浏览器;
  • 一个典型的 ASP.NET Web 应用程序,位于 Internet 的某个位置;
  • 第三方网络服务:
    • 位于另一个域中(通过联合域信任关系等没有关系);
    • 无法触摸/配置;
    • 可通过互联网访问;
    • 无连接;
    • 要求对每个 Web 请求进行身份验证;
    • 支持通用身份验证方案 (Windows) 并提供 SDK,允许在准备请求时设置凭据(用户名、密码)。
    • 不支持 OAuth 或类似技术,因此无法使用身份令牌代替凭据。

ASP.NET 网络应用程序将通过向第三方网络服务发出请求来实现其大部分功能。因此,Web 应用程序需要其用户的 Windows 凭据

ASP.NET Web 应用程序 将充当第 3 方 Web 服务的 UI 代理。此外,第 3 方 Web 服务不是单例的。 Web 应用程序应该是这些第 3 方 Web 服务(如此多的 Windows 域)的许多实例的 UI 代理。因此,Web 应用程序的行为类似于解复用 UI 代理 - 如果有这样的术语 :) 它代理了 3rd 方 Web 服务的多个实例。

现在我正在绞尽脑汁寻找一种通过网络应用程序将用户凭据(用户名、密码)从网络客户端传递到第三方服务的安全方法:)

在用户提供凭据之后,在工作会话开始时,直到工作会话结束,可以在哪里安全地保存凭据?我想到了各种媒体,例如:HTTP cookie、HTTP 标头、HTML 本地存储、服务器内存、Web 会话、应用程序数据库

关于上面的问题,什么是加密凭证的好方法,以便在需要时可以解密,即在准备对第三方 Web 服务的请求时(对称加密)?所有通信都是HTTPS

我知道这是一个奇怪的谜题:)

更新

也许让第 3 方 Web 服务支持代理身份验证模式(然后使用 OAuth 或类似的东西)是最好的。对吧?

更新:类似(或重复?)问题 - 似乎是一个热门问题

i *must* store third party credentials in my database. best way?

How to store user password for third party service in Python?

Security model: log in to third-party site with user's credentials

Storing third-party passwords for reuse across pages

What is the best way to store password in database when API call requires sending of password in plain text?

Encrypting 3rd party credentials

What's a smart way of storing user credentials for an external site (that does not use OAuth)?

Need to ephemerally store third-party password

Storing third-party auth info securely

Reversible password storage obfuscation method for third-party login credentials

storing the third party credentials in the database/some secure place

【问题讨论】:

  • 我认为最好的方法是保存会话令牌,而不是凭据。
  • 我的意思是,如果对方不实施,你就在你身边实施。
  • 不确定第三方服务如何需要您的Windows用户凭据
  • 如果所有用户都来自与第 3 方应用程序相同的 Windows 域,是否可以将您的 Web 应用程序托管在同一个域(即 Intranet)?然后集成 Windows 身份验证就可以工作了。
  • @user18044 谢谢 :) 不幸的是,托管第 3 方 Web 服务的 Windows 域不是 singleton。 Web 应用程序应该是那些第 3 个 Web 服务(许多 Windows 域)的许多实例的 UI 代理。因此,Web 应用程序就像一个多路复用 UI 代理 :)

标签: asp.net web-services security authentication encryption


【解决方案1】:

在这种奇怪的情况下没有最好的方法,但唯一的方法是将用户名和密码存储在应用程序会话中。这样至少您可以确保密码不会泄露给外部世界,并且在用户退出时也会自动删除。有权访问生产系统的人可以配置服务器并读取密码。您可能需要应用双向加密 (AES) 以使生产支持人员难以阅读。

您已经提到无法触摸第三方系统,我不确定您是否可以对凭据传递方式提出小幅改进。试试这个。

  1. 第三方接受由 ssh 密钥(公钥)加密的凭据。
  2. 您可以在用户提交给您后立即通过公钥加密凭据并保持会话状态。

在这种情况下,您身边的任何人都无法解密,但第三方可以使用私钥解密。您和第三方需要交换 ssh 密钥作为一次性设置。

【讨论】:

  • 感谢您提出使用非对称加密技术的想法。不过,也许应该使用第三方的公钥对凭据进行加密?因此,只能在其一侧(使用其私钥)进行解密。可以用公钥解密的数据并不是真正的秘密。如果我错了,请纠正我。 很遗憾,第 3 方系统真的不能碰。 我得调查一下“标准”(非自定义)Windows 身份验证方案是否支持您描述的想法。
  • 有人,请为 -1 添加评论 :)
  • 是的,你是对的。但是在您的场景中,您确实有纯密码,因此无论哪种方式都可能没有任何区别。更新帖子。谢谢
【解决方案2】:

鉴于您拥有许多此类第 3 方服务 (see comment),它们都位于客户的域中,因此您的 Web 应用程序(位于这些域之外)不应直接与第 3 方服务通信。

您的应用程序将成为黑客攻击的目标,因为它会明文处理用户的域凭据。

我认为唯一可行的解​​决方案是让用户的浏览器与第 3 方服务通信,以使用集成 Windows 身份验证 (IWA) 检索数据,然后将此数据发布到您的 Web 应用程序。

您必须在第 3 方应用程序上配置跨域资源共享 (CORS) 才能工作(或使用其他方式 circumvent the same-origin policy

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2020-10-22
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2011-02-28
    相关资源
    最近更新 更多