|

“使用我的 Windows 凭据”需要一个主体。在桌面程序中,主体可能是运行它的人。在服务中,主体可能是服务的帐户。在 Web 应用程序中,访问者成功登录并不会自动替换出站请求的安全上下文。

这就解释了为什么同一台机器上的浏览器和服务器端代码从集成身份验证代理那里可能得到不同的结果。它们可能呈现的是不同的身份。

在修改代码之前先给身份命名

  • 登录桌面浏览器的人。
  • 承载应用程序进程的帐户。
  • 出站操作中处于活动状态的任何模拟身份。
  • 代理实际接受或拒绝的帐户。

在 .NET 支持的集成身份验证路径上,DefaultCredentials 涉及当前的安全上下文。它不是任何在另一台机器上打开页面的人的全局别名。

如果产品有意以用户身份行事,那么模拟以及任何网络委派要求都需要各自受支持的设计。打开一个通用的“使用默认凭据”开关并不能建立这种设计。反过来说,一个打算以服务身份运行的后台作业不应依赖于有人先打开浏览器。

在去掉机密后比较交互式启动和已部署的启动:帐户上下文、代理终结点、声明的方法和被拒绝的身份。不要仅仅因为某次一次性请求成功就把桌面密码复制到应用程序里。配置应用程序应当使用的帐户,然后让这种归属在部署记录中保持可见。

相关文章