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

_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Reply via email to