Question

我正在现有的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，但我需要尽快实现这一点，我希望保持原始网站尽可能不受影响。

Answer 1

这不是一个糟糕的设计，这是你的要求，你试图实现它。我们有这样的工作系统，它不是火箭科学。唯一的区别是我们静态地（通过全局设置）将其切换为表单/ sam，而不是动态地。

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

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

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

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

我记得有一点需要注意。当用户通过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替换。）

设置STS但在webapp中保留formsauthentication

1 个答案: