使用Azure AD时处理Asp.Net MVC中的令牌超时 [英] Handle token timeout in Asp.Net MVC when using Azure AD

问题描述

这更多是设计/方法问题...

This is more of a design/approach question...

我想我在这里错过了一些东西.我们正在构建Asp.Net MVC 5 Web应用程序，并使用以下方案使用Azure AD保护它:

I think I'm missing something here. We're building an Asp.Net MVC 5 web application and securing it with Azure AD using the following scenario:

https://github.com/Azure-Samples/active-directory-dotnet-webapp-openidconnect

令牌/cookie绝对有效，一小时后失效.那么，这对用户体验有什么作用?他们每小时都必须重新登录，无论如何?在我们的测试中，当用户过期时，浏览器将重定向回AD，并提示用户输入凭据.当然，这会中断我们已加载部分视图的所有AJAX调用，因此所有DevExpress控件都不稳定.

The token/cookie is an absolute expiry and expires after one hour. So what does that do for the user experience? Every hour they have to log back in no matter what? In our testing, when the user expires, the browser is redirected back to AD and the user prompted for credentials. This, of course, breaks any AJAX calls we have loading partial views and none of our DevExpress controls are stable as a result.

基于对此SO帖子的回复:

Based on the response to this SO post: MVC AD Azure Refresh Token via ADAL JavaScript Ajax and KnockoutJs

...我所期待的是什么?在我看来，对于一个云托管的业务线应用程序来说，这似乎不是一个非常可行的解决方案，在该应用程序中，用户全天都已登录并可以正常工作.

...what I'm seeing is expected? It seems to me like not a very viable solution for a cloud hosted line-of-business application where users are logged in and working all day.

我错过了什么吗?还是这不是业务应用程序的理想方案?

Am I missing something? Or is this just not an ideal scenario for business apps?

推荐答案

我们面临着一系列类似的问题，以及关于如何在如此低的Web应用程序中将Azure AD与ASP.NET MVC结合使用的想法.会话超时(60分钟).

We faced a similar set of problems, as well as the same thoughts about how you could use Azure AD with ASP.NET MVC in web apps with such a low session timeout (60 minutes).

我们想出的解决方案似乎正在起作用(尽管经过了有限的测试)，但我们的页面上每隔5分钟就会刷新一次iFrame.

The solution we came up with, that seems to be working (albeit with limited testing), is to have an iFrame on the page that we refresh every 5 minutes.

<iframe sandbox="allow-same-origin allow-scripts allow-popups allow-forms" id="refreshAuthenticationIframe" src="@Url.Action("CheckSessionTimeout", "Home", new { area = "" })" style="display:none;"></iframe>

"CheckSessionTimeout"页面基本上是空白.

The "CheckSessionTimeout" page is basically blank.

在整个应用程序引用的Javascript文件中，我们具有:

In a Javascript file referenced by the whole app, we have:

var pageLoadTime = moment();

setInterval(refreshAuthenticationCookies, 1000);

function refreshAuthenticationCookies() {
    if (moment().diff(pageLoadTime, "seconds") > 300) {
        document.getElementById("refreshAuthenticationIframe").contentDocument.location = "/Home/ForceSessionRefresh";
        pageLoadTime = moment();
    }
}

(注意:moment是我们使用的JS日期/时间库).在Home控制器上，我们有:

(NB: moment is a JS date/time library we use). On the Home controller, we have:

    public ActionResult CheckSessionTimeout() => View();

    public ActionResult ForceSessionRefresh()
    {
        HttpContext.GetOwinContext()
               .Authentication.Challenge(new AuthenticationProperties { RedirectUri = "/Home/CheckSessiontimeout" },
                   OpenIdConnectAuthenticationDefaults.AuthenticationType);

        return null;
    }

我不确定这是否是最好的方法/方法.相对于我们要解决的问题，Azure AD和ASP.NET MVC应用程序(不是SPA，未使用Web API但正在使用Ajax调用)，似乎可以解决一系列困难的约束，这是我们能做的最好的事情从那里，这与执行Kerberos身份验证的本地应用无关(并且我们的用户期望会话超时是他们不希望看到或担心的事情).

I am not sure if any of that is the best way/approach. It's just the best we can do to fix up what seems like a set of difficult constraints with Azure AD and ASP.NET MVC apps (that are not SPAs, not using Web API but are using Ajax calls), relative to where we are coming from where none of this matters with on-premises apps doing Kerberos auth (and our user's expectations that session timeout is nothing they want to see or worry about).

这篇关于使用Azure AD时处理Asp.Net MVC中的令牌超时的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！