设置STS，但在Web应用程序中保留表单身份验证

本文关键字：保留 表单 身份验证 应用程序 Web STS 但在 设置 | 更新日期: 2023-09-27 18:27:21

我正在现有的web应用程序上启用windows标识基础。

我想尽可能少地干扰现有的代码，所以我想访问使用应用程序中保留的表单身份验证的登录页面，如果用户通过特定页面（例如"im_comming_from_some_other_site.aspx"）进入应用程序，我只需连接STS。

在"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的要求，但我需要尽快实现这一点，我想尽可能保持原始网站的原样。

设置STS，但在Web应用程序中保留表单身份验证

这不是一个糟糕的设计，这是你的需求，你会努力实现它。我们有这样构建的工作系统，这不是火箭科学。唯一的区别是，我们静态地（通过全局设置）而不是动态地将其切换到forms/sam。

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

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

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

你甚至不需要你在问题中提到的if。

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

但是，如果用户通过表单进行身份验证，则SAM（SessionAuthenticationModule）将在每个请求时用ASP.NET管道中的WS-Federation cookie替换表单cookie（我想这是因为SAM在形成身份验证模块的管道中较晚）。

这不会破坏您的context.User.Identity.IsInRole(...)授权也能正常工作，因为SAM会将用户角色复制到相应的声明中。

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

相关文章：