0

我被卡住了，需要一些建议或解决方案的指针。对于我们的单点登录实现，我有一个相当简单的 IdentityServer4 设置。

三个应用程序

IdentityServer4 与 asp.net 核心身份（ID 服务器）

ASP.NET Core 2.2 MVC (client1)

ASP.NET Core 2.2 MVC (client2) MVC 客户端是使用混合授权设置的

两种情况：

  1. 如果用户在任何一个客户端中处于活动状态（例如客户端 1），则在该应用程序（客户端 2）中达到空闲超时后，用户不应在客户端 2 中注销。
  2. 如果用户在两个客户端（client1 和 client2）中都处于非活动状态，则系统应在空闲超时超过时从所有客户端（client1 和 client2）中注销用户。

场景 1：用户活跃于任一客户端。用户在客户端 1 中处于活动状态，在客户端 2 中处于空闲状态 预期行为：超过空闲超时时，系统不应从客户端 2 中注销。当前身份行为：能够在client1中继续工作，但是client2和ID服务器在空闲时间超过后导航到登录页面。

场景 2：用户在所有 2 个客户端（客户端 1 和客户端 2）中均处于非活动状态 预期行为：当空闲超时超过时，系统应从所有 2 个客户端和 ID 服务器中注销用户。

如果我仅在 ID 服务器中设置 cookie 过期时间（删除了sliderexpiration 为 true 并且 client1 和 client2 中的 cookie 过期时间），那么即使两个客户端都处于空闲状态，直到 ID 服务器过期时间超过，客户端应用程序都可以连续工作而没有过期时间，客户端应用程序正在连续工作。

我想知道是否可以实现预期的行为

客户：

 .AddCookie(options =>
                {
                    // Configure the client application to use sliding sessions
                    options.SlidingExpiration = true;
                    // Expire the session of 15 minutes of inactivity
                    options.ExpireTimeSpan = TimeSpan.FromMinutes(15);
                })

身份证服务器：

services.AddIdentityServer(options =>
            {
                options.Authentication.CookieLifetime = TimeSpan.FromMinutes(15);
                options.Authentication.CookieSlidingExpiration = true;
            })
4

2 回答 2

1

我们采用的方法，我认为符合 OIDC 规范精神的方法是 IDP 会话是主会话并且可以长期存在。IDP 不关心客户端会话，但客户端应监控 IDP 会话（会话监控规范），并且当 IDP 注销时，客户端会话也应注销（前通道或后通道）。从客户端显式退出也应该让您退出 IDP 会话。

此外，由于协议支持prompt=login，max_age=n因此即使 IDP 上已经存在活动会话，您也可以强制执行交互式身份验证。这允许客户端实施他们自己的用户必须多久进行一次身份验证的策略——例如，要访问管理功能，您必须在过去 5 分钟内或类似的时间内进行身份验证。

如果在 IDP auth cookie 过期但开箱即用的情况下不会发生这种情况，那么如果会话监控在 IDS4 中启动，那也将是整洁的。但是，应该可以创建一个自定义的 IUserSession 实现，将会话 ID cookie 与主身份验证 cookie 正确对齐。

于 2019-07-15T09:17:28.563 回答
1

首先需要回答的问题是：什么系统，在哪里？

浏览器客户端不可信任且不应干扰。我认为最好恢复 cookie 设置。不要让前端尝试触发注销。

最好在后端跟踪用户。您可以通过在 Mvc 客户端中添加一项服务来实现此目的，该服务 1. 将用户注册为由 IdentityServer 激活，2. 跟踪活动，以及 3. 当用户看起来太长时间不活动时，通过 IdentityServer 取消注册用户。查看 IdentityServer 附带的令牌清理服务，以获取有关如何使用间隔更新列表的一些灵感。

在启动两个 Mvc 客户端时，为 cookie 添加一个处理程序：

Services
    .AddAuthentication(options =>
    {
        options.DefaultScheme = "Cookies";
        options.DefaultChallengeScheme = "oidc";
    })
    .AddCookie("Cookies", options =>
    {
        // you'll need to create your own handler
        options.EventsType = typeof(MyCookieEventHandler);
    })

我不会在这里添加代码，而是解释一下目的：每次用户需要访问安全源时都会调用 cookiehandler。这意味着您可以在此处更新用户活动时间戳（用于跟踪用户），这意味着您不必一直联系 IdentityServer。只有当状态发生变化时，服务才应该联系 IdentityServer：用户变为活动或不活动。

现在您需要向 IdentityServer 添加一个服务，以便在一个中心位置跟踪用户。您可以将用户的状态保留在商店中。当用户变为活动时添加用户（每个客户端），当用户不再活动时删除用户。当用户的最后一个会话从此列表中删除时，触发反向通道注销。

反向通道注销可以向 mvc 客户端发出用户已注销的信号。然后使用 CookieEventHandler 拒绝用户访问。这不会在注销时更新前台，但在用户联系 mvc 客户端时有效。它会发现自己已从所有应用程序和 Identityserver 中注销。

当您点击链接时，您将看到 CookieEventHandler 的实现。并在互联网上搜索backchannel logout，您可能会找到可以使用的示例。

于 2019-07-15T08:01:25.310 回答