集成 Windows 身份验证和SSL协议
我的 Intranet 上有一个管理网站,当前通过 IIS 使用集成 Windows 身份验证。我们希望将此应用程序移至公共网站并使用 SSL 对其进行保护,以便我们的用户可以从任何地方访问它。
我一直计划使用 HttpModule 从 http 重定向到 https,但看起来这不适用于集成身份验证(登录弹出窗口出现在重定向之前)。
我是否被困在 IIS 中使用“需要 SSL”复选框?这似乎对用户不太友好,因为如果用户忘记使用 https URL,他们会得到一个漂亮的胖错误页面,而不是温和的重定向。
在这种情况下你会怎么做?
I have an administrative website on our intranet that currently uses Integrated Windows Authentication through IIS. We would like to move this application to a public website and secure it with SSL so our users can access it from anywhere.
I had been planning on using an HttpModule to redirect from http to https, but it doesn't look like this works with integrated authentication (the login popup appears before the redirect).
Am I stuck using the "require SSL" checkbox in IIS? This doesn't seem all that user friendly since the user gets a nice fat error page instead of a gentle redirect if they forget to use the https URL.
What would you do in this situation?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
我每次都将其作为 IIS 问题解决,而不是代码问题:
从那时起,任何只需在浏览器中键入网站地址的用户都将收到来自 IIS 的快速重定向消息,该消息会将其发送到 SSL - 网站的受保护版本。
I've solved this as an IIS problem every time, not a code problem:
From then on, any user that just types the web site address into their browser will get a lightning-fast redirect message from IIS that sends them to the SSL-protected version of the site.
我们的 Intranet 站点上也遇到了类似的问题,最终从集成 Windows 身份验证切换到直接在站点上请求其网络用户名/密码。这样我们就可以将它们重定向到 HTTPS 或其他类似的东西,而不必担心身份验证弹出窗口何时出现。
我们有一些与此类似的代码(假设您使用的是 ASP.NET)来对用户进行身份验证,然后我们将身份验证状态存储在 cookie 中。
通过在应用程序中处理所有身份验证而不是依赖 IIS,它最终为我们节省了大量的麻烦和挫败感。
We had similar issues on our intranet site and ended up switching from Integrated Windows Authentication to requesting their network username/password directly on the site. That way we can redirect them to HTTPS or other such things without worrying about when the authentication popup shows up.
We have some code similar to this (assuming you're using ASP.NET) that authenticates the user, and then we store the authentication state in a cookie.
It ended up saving us tons of headache and frustration by handling all authentication in the application rather than depending on IIS.