我正在编写一个内部Web应用程序（使用ASP.Net Web Forms），这是一个奇怪的问题。我必须能够模拟当前登录的Windows用户，并根据他们的Windows身份验证执行命令登录..并且...如果他们没有在我必须使用的应用程序中设置Windows身份验证登录，我必须能够接受用户名和密码。我还必须在.Net 4.0中编写应用程序，并尽可能地保护它。我通过在web.config中不使用Windows身份验证或表单身份验证来实现这一点，而是设置会话变量以防止用户访问Web应用程序中的其他登录页面。我通过创建奇怪的名称会话变量来实现此目的使用基于用户名的值（windows auth或不是），然后是一个秘密会话变量。秘密变量在web.config中作为256位加密字符串，我在其中解密，并设置为会话密钥。为了加载页面，第一个会话变量不能为空，第二个变量必须等于解密的键值...如果变量没有通过检查，它会将它们重定向到登录页面。我在Web应用程序中的每个页面，通用处理程序和webservice方法上进行了设置。我在没有活动几分钟后使会话超时，并且在注销时，我将所有会话变量设置为空，并使所有cookie失效。 （我也禁用所有缓存）。
我的问题是......这是否提供与Forms身份验证相当的安全性？我一直使用Forms身份验证，但不能在这里使用它。如果我这样做，用户将不得不在IIS和web.config中重新配置设置以切换登录过程（据我所知，您不能同时使用Forms身份验证和Windows身份验证来管理页面和其他Web的安全性资源）。通过上述方法，我可以实现两全其美，但我很好奇我的方法的安全性。还有什么我可以在这里实现，以确保使用表单身份验证的最大安全性？是否可以在不使用Forms身份验证的情况下实现相同级别的安全性？
感谢您提前了解任何见解！
答案 0 :(得分：5)
这是否提供与Forms身份验证相当的安全性？
否
关于安全性的第一条规则是不要重新发明轮子，除非你绝对必须这样做。您提出的任何家庭烘焙解决方案都具有 potential 与Windows或Forms Authentication等提供的解决方案一样安全。问题是本土解决方案很少能达到这种潜力。他们可能会测试好，但可以保留微妙的错误。你不想在一年后发现六个月前你被黑了。现有的解决方案已经在数百万个应用程序中进行了测试和使用，而您的解决方案将在一个应用程序中使用，并且最多只能由少数人进行测试。
快速搜索表明可以在同一个应用程序中实现Windows和Forms身份验证，因此我会进一步追求它。