表单身份验证跨 Windows 身份验证
我正在开发一个网站，该网站同时具有 Intranet 和 Internet 部署。两者之间的唯一区别是一些配置设置。
互联网版本工作正常，因为它只使用表单身份验证（在其 Web 配置中定义），如果未登录，用户将被定向到登录页面。
Intranet 版本有点棘手...当用户第一次访问该站点时，使用 WindowsPrincipal 正确设置了 http 上下文原理对象，但使用该信息我确认允许用户访问该应用程序，然后创建自己的应用程序IP原理实例。
鉴于此，我想在这里做几件事...我想使用 WindowsPrincipal 对象作为对用户进行身份验证的基础，但从那时起，使用表单身份验证（即使用 cookie 来存储身份验证详细信息等） ）。我还需要从 HTTP 上下文中检索的原则实例属于我的 IPrinciple 类型。
我最好如何去做这件事？就像我应该查看 global.asax 的 Session_Start 来执行身份验证逻辑，然后以某种方式让它存储我的自定义 IPrinciple （因此对于该点之后的任何请求，该实例是我的自定义原则），还是我最好使用 Application_AuthenticateRequest 做一些事情。
干杯 安东尼
I have a website that I am working on that has both an intranet and internet deployment. The only difference between the 2 is a couple of config settings.
The internet version works fine as it just uses forms authentication (which is defined in its web config) and if not logged in the user is directed to a login page.
The intranet version is a little trickier... when a user first comes to the site the http context principle object is set correctly with WindowsPrincipal, but using that information I confirm that the user is allowed access to the app and then I create my own IPrinciple instance.
Given this there are a couple of things I want to do here... I want to use the WindowsPrincipal object as a basis for authenticating the user but then from that point forward use forms authentication (i.e. using a cookie to store the auth details etc). I also need the instance of the principle that I retrieve from the HTTP context to be of my IPrinciple type.
How am I best to go about doing this? As in should I look to the global.asax's Session_Start to perform auth logic and then somehow get it to store my custom IPrinciple (so for any request after that point the instance is my custom principle) or am I best to be doing something with Application_AuthenticateRequest.
Cheers
Anthony
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
为此避免使用会话对象。 Application_AuthenticateRequest 就是您想要的位置。在那里，您可以获取 WindowsPrincipal，然后转到数据库来填充您自己的自定义 IPrincipal 实现对象。不过，这意味着 Application_AuthenticateRequest 会被多次调用，因此在我的应用程序中，我倾向于将角色数据缓存至少几秒钟，以减少数据库往返次数。这也适用于表单身份验证。这两种方法之间的唯一区别是，在 Forms 场景中，您从 Forms 身份验证模块获取 GenericPrincipal，并且您可以使用它来检索您自己的自定义主体对象，而不是 WindowsPrincipal。
在 Application_AuthenticateRequest 中设置 HttpContext.Current.User 的另一个好处是，与将主体放在 Session 对象中不同，您可以使用声明性安全性，例如使用 PrimaryPermissionAttribute 装饰您的方法。
Avoid the session object for this. Application_AuthenticateRequest is where you want to be. In there, you can take the WindowsPrincipal, and then go to the database to populate your own custom IPrincipal-implementing object. This means that Application_AuthenticateRequest gets called a lot, though, so in my apps, I tend to cache the role data for at least a few seconds to cut down on database round trips. This also works with Forms authentication. The only difference between the two methods is that in the Forms scenario, you get a GenericPrincipal from the Forms auth module, and you'd use that to retrieve your own custom principal object instead of the WindowsPrincipal.
Another upshot of setting HttpContext.Current.User in Application_AuthenticateRequest is that, unlike if you put your principal in the Session object, you can use declarative security, such as decorating your methods with PrincipalPermissionAttribute.