#2361 Session expiration policy
Closed: fixed 5 years ago Opened 12 years ago by edewata.

There should be two different session expiration policies:

  1. For Kerberos-based authentication the session should have a shorter expiration time (e.g. 5 minutes) and the client (i.e. UI) should automatically renew the session so the user should not notice anything. This way when the user does a kdestroy the UI session will expire automatically not too long after that. The user may also log out manually from the UI.

  2. For form-based authentication the session should have a longer expiration time (e.g. 20 minutes) and the timer should be reset on every user activity. This way a user can continue to use the UI unless it's been left idle or the user logs out from the UI manually.


What is the value of doing it differently? We keep it longer for password auth but shorter for GSSAPI negotiation auth. Dean not make much sense. Also when we add cert authentication in future or allow 2FA via forms based auth we will still use the same session lifetime as with password. IMO if just adds complexity but does not add any security to have more then one session timeout as you proposed. It would makes sense to allow kerberos based session stay longer but then again why not the same time.
IMO this ticket should be closed as WONTFIX.

This is to prevent this case:

- kinit someuser
- firefox https://ipa.example.com/ipa/ui
- kdestroy

firefox will still work for an hour with the cached TGT. The feeling is that an hour is too long, but shortening it too much will adversely affect forms-based login users.

It is very simple.
Ideally you want a short session timeout for negotiation so you are bound to the TGT expiration time (or the user simply using kdestroy).

If the TGT is expired or kdestroy is used you do not want to have the browser still be able to access the administrative interface with full powers for a long time. Before we introduced sessions authentication was performed at every action and therefore a kdestroy would immediately terminate the user's ability to perform any operation. Of course we cannot immediately expire the session or we would give away the performance gains we achieved by introducing sessions in the first place. But sessions should still not be overly long when using negotiate auth.

Unfortunately when using form based auth it makes no sense to keep prompting the user for a password very often. In the case of form base auth the concept of session expiration has to be entirely different and must depend on 'use' of the interface. As long as the user keeps uing it we should not arbitrarily expire the session in the middle of the admins work. This is why form based sessions expiration should be dynamic and not statically determined as X minutes after the initial login.
The session timeout in this case should be reasonable so that a session does not last too long, and yet not too short to avoid the need for a user to keep re-authenticating.
In general 20 minutes is considered a good compromise to determine "continuous' activity on a web page.
We can, of course, change this value if necessary. Even better if we make all timeouts easily configurable by admins, so that local policies (if any) can be implemented.

It does not make sense to have a time out for the kerberos based session less than for the forms based session from the security point of view. So I fail to understand what this flexibility of two timeouts would accomplish. We can just take the second approach of 20 min and keep it while person is using it regardless whether the ticket expired or not. User password could have been reset, cert revoked, ticket removed - the session should continue regardless for a predictable time in a consistent way.

One possible scenario is that a user might do a kdestroy and leave the workstation thinking he has logged out from all applications whereas the browser session is still active for another 20 minutes.

This is what the logout button should be for.

BTW do we check whether the account is enabled? If the account is disabled in the middle of the session the session should be destroyed regardless of how the original cookie was acquired. If it is not done please file a ticket.

Without this ticket, the user would have to remember to logout both from the command line using kdestroy and from the UI using the logout button to ensure nobody can exploit the active browser session. It might not be a big issue, but this ticket could reduce the risks if he forgets to logout from the UI.

Another usage for this ticket is for updating the UI when the user's rights are changed. Suppose the admin removes a user from the admins group, the UI will switch to self-service change within 5 minutes.

How frequently people explicitly call kdestroy? I think you would agree that this is not a common practice.

So if user authenticated from a system which is enrolled with IPA he will have one set of expectations about his session and if he logged from other machine that is not enrolled he should have another? I do not think that it is wise to have different expectations depending on how the original authentication was conducted.

Cookie is the extension of the ticket. If you want the total lifetime of the SSO be no longer than ticket lifetime make ticket lifetime + cookie equal to the current ticket lifetime. It is one time policy decision. You do not have to educate users and explain why the system behaves differently.

I do not like the idea of different behavior depending on the authentication method. If one does not like cookies - use what we have now and disable the sessions altogether.

It doesn't really matter how long does the session last. It has to behave differently for Negotiate authentication vs form based authentication.

And given it has to behave differently it is more secure to reduce the session expiration time for Negotiate auth so that authentication is more frequently verified (completely transparent to the user).

The reason why form based auth sessions needs to behave differently is that you cannot reasonably tell a user that he has to enter back his password every 20 minutes potentially in the middle of a change. And having form based authentication expire after a longer period of time is not a good idea.

Sorry Simo I fail to understand why they should be different. I agree it is unreasonable to tell the user to re-authenticate with password every time or too frequently. I also agree that long time time is not a good idea for the forms based authentication. What I fail to understand is why the negotiation path should be different from the forms based path. They all should behave the same and follow the forms based auth pattern. So far have not seen any argument why then negotiate path has to be different from the forms based path.

Negotiate is based on the assumption that the client TGT is used, so a session established using the user ticket should ideally terminate as soon as those user credential expire (TGT expired) or they are revoked (kdestroy). We can get close to this ideal only by keeping the session expiration time for the session reasonably low.

Form based auth instead is completely different, we need to keep extending the session expiration time in the future for as long as the user continuously uses the system.
By 'continuously uses the system' generally it is meant that the user interact with the server at least once every X minutes (where X is often set to 20). If the user interact with the system within X minutes, the session expiration time is automatically extended by another X from the interaction time, and so on until either the user logs out or stop interacting for X minutes and the session finally expires.

If we use this second method with Negotiate auth it means the user would be able to continue to use the server even after he kdestroy for as long as the LDAP ticket stored in the session is valid, as the session itself would continue to be extended regardless of whether the user still has a valid TGT on the client. This is not what you want to allow when using Negotiate auth.

This is where we disagree. I see the session cookie is an extension of the ticket.

"If we use this second method with Negotiate auth it means the user would be able to continue to use the server even after he kdestroy for as long as the LDAP ticket stored in the session is valid, as the session itself would continue to be extended regardless of whether the user still has a valid TGT on the client. This is not what you want to allow when using Negotiate auth."

I am failing to understand why it is a bad idea? It is exactly what we should be doing to give the consistent user experience regardless of how user authenticated.
Once I authenticated to a service I expect to be able to use it for some time and timeout after the period of inactivity. IMO we should have a timeout to force re-authentication something like max cookie lifetime and set it to couple hours by default. But this is a side point. Please explain why exactly "This is not what you want to allow when using Negotiate auth.".
How it is worse from a security point of view to continue user session when user password was centrally reset or user cert has been revoked?

It is the same reason we get complaints from users when the kernel keeps using their negotiated session to access NFS directories even after the user did a kdestroy.

When you use kerberos your TGT is the only token that matters, and users expect all services to stop working if you explicitly kdestroy as they are explicitly asking the system to stop using those credentials.

This is the standard expectation. And given we can do it transparently (albeit with a minor delay of a few minutes) we should do it.

OK, then we should have it configurable because there is another set of users who do not complain and do not do kdestroy and do not care if kerberos is used under the hood. They expect consistency regardless of how they authenticated. The configuration option should define how the the sessions based on negotiation would behave. I would agree that it should default to a more secure path and behave as described in the first approach. But there should be a way to turn it and make it consistent.

If this can't be solved in this ticket please create a different ticket to add this configuration option.

The second set of users that never kdestroy do not need anything special.
From the users point of view the scheme we propose in this ticket is perfectly consistent. Users won't see a difference except in the case they explicitly kdestroy when using Negotiate auth.

Their session will continue to work as long as their ticket is valid and it will be transparently updated every once in a while.
Of course their session will stop working once the TGT expires as their LDAP ticket will also expire and they will have to get a new TGT (or switch to form based auth).

Yes but the problem with this approach is that it stops abruptly for no reason. If you authenticated using forms based auth and have been doing your work you would be able to continue indefinitely while the TGT based auth would expire abruptly. So in this case there should be the configurable maximum lifetime of the session so that you have to authenticate from time to time. I would make it default to 12 hours.

The problem is these really are two completely separate cases.

In the case the user holds the TGT we can set the session expiration until the cows come home and we're still bound by the TGT expiration. Once it expires game over.

In the case we hold the TGT (forms-based) we can may be able to renew it as necessary, though I don't know that we'd want to.

It is in large part a control issue as simo said. If I'm trying to secure my workstation and I do a kdestroy I have every expectation that it is no longer usable. If it will be available for another 12 hours just because I happened to look myself up in the UI is not good.

User's won't notice us re-checking the session in any case beyond a slightly slower request now and then, at least until the point their TGT expires and they get a failed page. They get that now though so I don't see how this is unacceptable.

In the case we hold the TGT (forms-based) we can may be able to renew it as necessary, though I don't know that we'd want to.

We do not. I agree.

What I do not understand is why it is not OK to expect that session would die in 20 minutes if I stopped typing and not run kdestroy? It should die in either case. But in what Simo proposes it will be active until my TGT expires.

Think about the use cases:
1. I authenticated with password via form, did something in UI, closed my laptop and left - my session will automatically die in 20 min and all server side cached data will be destroyed.
2. I authenticated with negotiated ticket, did something in UI, closed my laptop and left - my session will stay for the life of the ticket which will be usually more than 20 min.

In the second case the attacker has more time to try to hijack the abandoned session. So what I suggest is in both cases make session expire after 20 min of inactivity or when the ticket we have in cache expires - whichever comes first.

Replying to [comment:18 dpal]:

In the case we hold the TGT (forms-based) we can may be able to renew it as necessary, though I don't know that we'd want to.

We do not. I agree.

What I do not understand is why it is not OK to expect that session would die in 20 minutes if I stopped typing and not run kdestroy? It should die in either case. But in what Simo proposes it will be active until my TGT expires.

I think you misunderstood, we are propsing exactly the opposite.

We are proposing that the session expire after 20 min. (but with automatic renewal of expiration time if a user is active) for form based.
We are proposing that the session expire after 5 min. in the Negotiate case.

The point is that in the negotiate case the browesr will autmatically and transparently establish a new session if you are working on the page thanks to transparent Negotiate (SSO) auth.

So the "session" itself is very short (5 min.) in the Negotiate case, but new sessions can be established transparently so the user won't notice.

Metadata Update from @edewata:
- Issue assigned to rcritten
- Issue set to the milestone: Ticket Backlog

7 years ago

Code to manage the kinit session lifetime when a user authenticates with username/password was added in ipa-4-6 with 77db574 via ticket https://pagure.io/freeipa/issue/7001

Metadata Update from @rcritten:
- Issue close_status updated to: fixed
- Issue status updated to: Closed (was: Open)

5 years ago

Login to comment on this ticket.

Metadata