c# – 设置STS但在webapp中保留formsauthentication

2023年8月3日 155次阅读

我正在现有的webapp上启用
Windows身份基础.

我希望尽可能少地使用现有代码,因此我想要使用应用程序中剩余的formsauthentication的登录页面,如果用户通过特定页面输入应用程序,我只需连接STS,例如“im_comming_from_some_other_site.aspx” .

在“im_comming_from_some_other_site.aspx”中代码如下：

Page_Load(...)
{
   if(verifyAgainstSTS()
   {
        FormsAuthentication.SetAuthCookie(<some_STS_Userid), ...)
        Response.Redirect("default.aspx")
   }
   else
   {
        Response.Redirect("http://<STS_server_name/<STS_service...etc>")
   }
}

是否有人知道是否可以这样做以及如何做？任何链接到示例代码(如果可用)深受赞赏.

(当验证超时时,当确定要做什么时,需要一些代码;要么转到本地登录页面,要么转到STS登录页面)

我知道这可能看起来像一个糟糕的设计,而不是一直用STS,但我需要尽快实现这一点,我希望保持原始网站尽可能不受影响.

最佳答案 这不是一个糟糕的设计,这是你的要求,你试图实现它.我们有这样的工作系统,它不是火箭科学.唯一的区别是我们静态地(通过全局设置)将其切换为窗体/ sam,而不是动态地.

无论如何,您将表单身份验证保留在web.config中,这样当没有当前用户的授权时,表单会将请求重定向到登录页面.

在登录页面中,您有两个选项.一个人以某种方式创建表单cookie.
另一个选项涉及WIF的FederatedPassiveSignIn控件.

如果用户遵循表单身份验证,则会设置cookie并完成操作.
如果用户遵循STS登录控制,他/她迟早会带着有效的SAML令牌返回. FederatedPassiveSignIn将自动选择它,您只需处理SignedIn事件中的重定向.

如果你在问题中提到,你甚至不需要.

我记得有一点需要注意.当用户通过STS进行身份验证时,会创建WS-Federation cookie,您可以读取声明等.一切正常.

但是,如果用户通过表单进行身份验证,则SAM(SessionAuthenticationModule)将在EACH请求时通过ASP.NET管道中的WS-Federation cookie来替换表单cookie(我猜是因为SAM稍后在构成身份验证模块的管道中) .

这不会破坏你的context.User.Identity.IsInRole(…)也可以正常授权,因为SAM会将用户角色复制到相应的声明.

但是,如果您在代码中的任何位置尝试直接从表单cookie中提取信息(而不是使用常规API),您可能会发现表单cookie不存在,即使用户首先通过表单进行身份验证(并且cookie不存在,因为它将被WS-Federation cookie替换).

点赞