Idle-Timeout in ASP.Net Core 3.1 with Windows Authentication

Question

Edit

Letz Keep it simple.

How to implement idle-timeout in .Net Core 3.1 Application with Windows Authentication?

Why with Windows Authentication : Because when authentication happens with Windows (Active Directory) we cannot logout.

Idle-Timeout: This feature means if the screen is idle for Some time (can configure in IIS -> Application Pools -> Select Pool -> Advanced Settings -> Idle Timeout : (Default:20mins)) the application should logout and ask for login again. or it should go to page 404 which is set in the startup.cs

Good to have

Using Windows Authentication
Trying to implement idle-timeout from IIS Application Pool.
It should (also) work after deployment to IIS.

Current Behaviour

The application shutdown after idle-timeout.

and

tries to browse (Click on any link) it starts the application again

Tries to logout windows authentication but no luck

Expected Behaviour / Output

Login dialog popup for Windows Authentication

and / or

After idle-timeout should reach 404

The IIS Worker Process (Application Pool) setting for Idle Timeout has absolutely nothing to do with the end-user being idle nor Windows Authentication (Kerberos or NTLM). It is only concerned with reducing memory load on the server when an application is inactive (w.r.t. processing HTTP requests, regardless of what the end-user is doing in a browser window or any background tasks running inside the worker process). — Dai
@Dai: I am sure you are correct. thus it is not working. Can u give little more guidance towards the functionality — Mohit Shrivastava
Use AJAX (well, fetch) in the page or service-worker to send requests every few minutes to keep the user's authentication token alive - but I'll admit I'm unsure how this works with Kerberos/NTML. — Dai
Using windows auth, your browser will login whenever the server returns a 401 response. But may auto-login with a cached username / password or current local user token. I don't believe there is a way to force the browser to prompt. — Jeremy Lakeman
@JeremyLakeman: NP. I got that but there will certainly a way out for 404. That means after idle timeout expire it reaches to 404 thats it — Mohit Shrivastava

Adam Schiavone Adam Schiavone · Accepted Answer · 2020-10-26T16:19:23

I think what you're asking for is not directly possible, but you could get close. I'm not going to offer any code here, as this could get complex, however I hope it helps you think about the problem. I agree with @jeremy-lakeman that this is an "anti-feature" that you're looking for, and maybe you can reframe the problem.

Windows Authentication

Windows will automatically authenticate via kerberos when the server sends back a 401. This is transparent to the user, and there is no login page. In your case, this is handled by IIS. At no point when using Windows Authentication should you be showing a login page.

Cookie Authentication

Essentially this is storing a cookie on the browser that is used to authenticate the user. Asp.Net Core 3.1 includes this natively, and can easily support this. The cookie is authenticated at the application level. This cookie can have an expiration, and you have a login form embedded in the page. When you create a new project, this is the "Individual Accounts" option.

Hybrid of the two

Imagine a world as follows:

You have two applications. Your primary app is configured with Cookie Authentication (we'll call it "Primary"), and a secondary app is configured to use Windows Authentication (called "Secondary"). You could also conceivably do this with IIS and put Windows Authentication for one particular path, but its easier to think about it as two separate apps.

When you make a request to Primary, your app validates the cookie. If no cookie exists, or its rejected (because the timeout hit) you are redirected (not a 401 Unauthorized, a 302 Found) to Secondary, which all it does is Windows auth. It could regenerate the cookie, and then send you back to Primary.

However this does not show you a login page, and I think that is the crux of the issue here. You want to have both automatic login, and manual login in the same application. If you have automatic login, what good is an expiration? They'll just refresh and get authenticated again.

If you ditch the idea of automatic login (via Windows Authentication) you can use only one application with Cookie Authentication.

Cookie only

In this scenario, you only have Primary setup, and it only does cookie authentication. You can have an Identity Provider that authenticates against Active Directory. This is Windows Auth, but on the application level, instead of at the IIS level.

You're going to have to choose between Automatic Logins, or Timeouts. There is no reasonable world where you can have both.