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

[Dmitri Pal]

On 02/14/2012 01:01 PM, 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?
>

AFAIU the session ID will be (should be) lost when you switch the
principal and new ID returned to the browser.
The old session is still valid for 20 min if you did not log out but it
should not be accessible.
It seems that everything depends on what is the key for the internal
cache. I would think that the key should be principal+session ID and
session ID is long and strong. We said in one of the earlier discussions
that it should be at least 128 bits of entropy. Was that done? If not
please log a ticket.

So am I right that the key is principal+session ID? If it is just
principal then yes the session can be resurrected but I do not think we
want this. If the key is just the ID there is a potential of the
privilege escalation if one principal tries to guess the ID for another
active session. Very unlikely but it seems that it is safer to have it
as a composit key. May be we should file an RFE on this. 


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

Old session should not be accessible.

> 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.
>
> Would it be possible for someone from another machine to randomly
> guess a session ID and then take over an existing authenticated session?
>
Then we need to make ID even longer.

-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IPA project,
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/