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

[Endi Sukma Dewata]

On 2/15/2012 8:01 AM, Simo Sorce 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).

Even if we make it shorter (e.g. 5 minutes) there's still a window where 
the browser is still using the old session. Will this be OK since it's 
not about somebody leaving the machine idle, but in this case someone 
else is taking over the machine while there's an active session? Also, 
both users might not be aware about the length of this window.

> 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.

Right, this is not the concern.

>> 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.

Assuming there is a way for the server to detect principal change 
earlier than session expiration, the server could either (a) reuse the 
same session but with new credentials, or (b) it could create a new 
session for the new user. In option (b) there's a possibility to keep 
the old session (thus the question about reusing the old session), but I 
don't think we want to do that.

If the assumption is wrong, the only possible option is (b), but in this 
case the old session is no longer available.

>> 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.

That's true if the above assumption is wrong. We're already planning to 
execute a whoami operation after each authentication so the UI can 
detect the change.

>> 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.

Hey... many people have won the lottery :)

> 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.

Agreed, although the form based auth is still exposed to the same 
hijacking issue.

-- 
Endi S. Dewata