【问题标题】:Forms Authentication cross Windows Authentication窗体身份验证跨 Windows 身份验证
【发布时间】:2009-08-25 03:11:42
【问题描述】:

我正在开发一个网站,该网站同时具有 Intranet 和 Internet 部署。两者之间的唯一区别是几个配置设置。

互联网版本运行良好,因为它只使用表单身份验证(在其网络配置中定义),如果未登录,用户将被定向到登录页面。

Intranet 版本有点棘手...当用户第一次访问该站点时,使用 WindowsPrincipal 正确设置了 http 上下文原则对象,但使用该信息我确认允许用户访问应用程序,然后我创建我自己的 IPrinciple 实例。

鉴于此,我想在这里做几件事...我想使用 WindowsPrincipal 对象作为对用户进行身份验证的基础,但从那时起使用表单身份验证(即使用 cookie 来存储身份验证详细信息等)。我还需要我从 HTTP 上下文中检索到的原则的实例是我的 IPrinciple 类型。

我最好怎么做?就像我应该查看 global.asax 的 Session_Start 来执行身份验证逻辑,然后以某种方式让它存储我的自定义 IPrinciple(因此对于此后的任何请求,实例都是我的自定义原则)或者我最好使用 Application_AuthenticateRequest 做一些事情.

干杯 安东尼

【问题讨论】:

    标签: .net asp.net forms-authentication windows-authentication


    【解决方案1】:

    为此避免使用会话对象。 Application_AuthenticateRequest 是您想要的位置。在那里,您可以获取 WindowsPrincipal,然后转到数据库以填充您自己的自定义 IPrincipal 实现对象。这意味着 Application_AuthenticateRequest 被调用了很多,所以在我的应用程序中,我倾向于将角色数据缓存至少几秒钟,以减少数据库往返。这也适用于表单身份验证。这两种方法之间的唯一区别在于,在 Forms 场景中,您从 Forms auth 模块中获取一个 GenericPrincipal,并且您将使用它来检索您自己的自定义主体对象,而不是 WindowsPrincipal。

    在 Application_AuthenticateRequest 中设置 HttpContext.Current.User 的另一个结果是,与将主体放在 Session 对象中不同,您可以使用声明性安全性,例如使用 PrincipalPermissionAttribute 装饰您的方法。

    【讨论】:

    猜你喜欢
    • 1970-01-01
    • 2017-08-13
    • 1970-01-01
    • 2010-10-05
    • 2013-10-30
    • 1970-01-01
    • 2012-03-15
    • 1970-01-01
    • 2015-07-18
    相关资源
    最近更新 更多