.net web应用程序如何应对Windows帐户的定期密码更改

我有一个配置为匿名访问的网站，其中包含一个HttpHandler，它通过“EndUserSite”中的代码发布。为了执行其工作，HttpHandler.ashx在调用webservice（在另一个需要Windows身份验证的站点上配置）之前设置一个显式凭据。按顺序，它的流程如下：

EndUserSite…使用表单身份验证…然后最终将发布到

HttpHandlerSite

srv.Credentials=new System.Net.NetworkCredential（“用户”、“通过”、“域”）；//当前硬编码

srv.webMethodName（

WebServiceSite…webservice对应用程序服务进行API调用（在不同的计算机上）

应用程序服务返回其调用者（Web服务）

Webservice返回其调用者（HttpHandler）

HttpHandlerSite streams将内容返回到当前HttpContext，即EndUserSite用户

整个操作不在一个域中，而是在一个工作组中的两台服务器中，并由“商定的”Windows标识“绑定在一起”

• ApplicationService（ServerA）配置为使用特定的Windows帐户运行
• WebServiceSite（ServerW）配置为使用匹配的Windows帐户运行
• HttpHandlerSite（ServerW）配置为匿名，但“知道”WebServiceSite的特殊用户名和密码（其用户名和密码凭据与ApplicationService“匹配”）

目前，凭据是在HttpHandler.ashx中硬编码的，该文件被组装到bin/webclient.dll中；还使用了强密码

虽然这一切都是可行的，但当“魔法密码”必须更改时，会出现“维护问题”。简言之，密码必须在多个位置更改，这些更改需要仔细协调

有没有更优雅的设计方法

我最担心的是必须修改源代码、重建HttpHandler并重新部署.DLL（其他更改可以由系统管理员处理）

---

我看到过一些关于代码访问安全性的大文章。这会有帮助吗？

你不能将用户名和密码保存在Web.Config文件中，而不是硬编码，这样你就不需要重新编译了。我在想这个问题，但是更新Web.Config部分的纯文本密码似乎有点“暴露”了。我假设当编译到webclient.dll中时，这些“常量”基本上是“不可见的”。也许这种假设是错误的（即任意.dll的“可黑客性”有多大？）。如果有人在您的服务器上并且能够读取您的密码，我认为您需要更加担心。使用reflector可以轻松读取dll-您可以加密配置文件