#215 Web UI should maintain state via session
Closed: Fixed None Opened 13 years ago by dpal.

Currently the UI is stateless and each request requires GSSAPI authentication. This is too costly. Using cookie might be much better alternative from performance POW. Also the session cookie can maintain state and other critical information that will help make UI more usable. For example it might keep the permissions for the user so that add/update/delete buttons get disabled when the user does not have permissions to perform operation.


I think this has some potential drawbacks that are worth considering. Currently, we don not use a cookie, and all state resides inside the IPA application. So long as kinit is up to date, the application works correctly. With the session, we will have yet another way to fail, which is valid kinit, but session timeout. Also, security with sessions is yet another layer to watch for problems.

Typically, in a web app, a session time out is indicated with a new prompt for UI/Password. We will have to silently start a new session. If the user has turned off the kerberos UID/Password, allowing basic auth, we might have two paths to deal with.

We can (almost certainly) set up the JSON RPC mechanism to always send the auth information, to avoid the double round trip. We should also figure out if there is a better way to set up the Kerberos ticket used for the Web so that it can be used for requests to modify ther users information directly.

The session security issue is a real one because we are going to have to store the TGT in the session. Jason had devised some code to keep the session encrypted, I don't know if that ever made it in the tree or what state it is in.

I don't think the session timeout is going to be a problem. The authenticated URI is going to be different from the regular URI. When the session times out (or we detect that the ticket in the session has expired) we redirect the browser to the authenticated URI. When the browser sees this for kerberos auth it runs through another authentication. If the user has a current ticket then the new TGT is cached and things proceed as expected, with a slight pause. If they have selected basic auth then the browser wills end its cached copy of username/password and again, it should be pretty smooth.

This is needed by ticket #981.

closing this because essentially the same thing was implemented as part of the session work which was just added to 2.2.

Metadata Update from @dpal:
- Issue assigned to pzuna
- Issue set to the milestone: Tickets Deferred

7 years ago

Login to comment on this ticket.

Metadata