[Freeipa-devel] [PATCH 61] Cache authentication in session

[Simo Sorce]

On Tue, 2012-02-14 at 12:01 -0600, Endi Sukma Dewata wrote:

> If someone already has a session then changes to another principal, will 
> he get a new session and then reauthenticate against the login URL? Or 
> will he use the same session but just reauthenticate?

I guess it depends on what you mean by "changes to another principal".
If you mean a simple kdestroy/kinit, then the interface will not see the
change until the session expires. (Which is why I want a session
expiration much shorter for Negotiate auth).

However if the user presses the logout button in the UI his session will
be destroyed and so the next attempt will cause a new negotiation to
happen and the UI will change to use the new principal.

> What if he then changes back to the previous principal, will he reuse 
> the old session? If so will he be required to authenticate again?

What old session do you refer to ?
The previous session of the same user has been destroyed, the other user
session is still valid until it expires or the user presses log out, so
nothing changes there.

> I think if the principal change is always preceded by reauthentication, 
> the UI will only need to redo the whoami after successful login. 
> Otherwise, the UI will need to check the principal change after each 
> operation like in the current code.

The UI will know when the principal changes because it will get an error
and it will be told to go to the re-authentication URL. When you
re-authenticate you should always check if the principal changed.

> Would it be possible for someone from another machine to randomly guess 
> a session ID and then take over an existing authenticated session?

The session ID is currently a 48bit random number (we ask John to make
it a 128bit number). *Guessing* that number is going to be *very* though
(read technically impossible if the randomness is properly handled at
the creation of the session ID in the server.
However if somehow the sessionid is exposed than an attacker can hijack
the connection. The risk is extremely low, but it is another reason why
having a short expiration for Negotiate auth would be better, than
treating it the same as form based auth.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York