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

Endi Sukma Dewata edewata at redhat.com
Tue Feb 14 18:01:32 UTC 2012


On 2/9/2012 8:32 AM, John Dennis wrote:
>> Currently when the UI is loaded for the first time it will execute an
>> ipa_init operation which consists of:
>>
>> 1. Loading I18 messages.
>> 2. Getting user info (whoami).
>> 3. Loading environment variables.
>> 4. Checking whether DNS is enabled.
>> 5. Loading objects& commands metadata for labels and validations.
>>
>> Right now if the UI detects a change in the principal name or server
>> version it will reload itself and so it will execute the ipa_init again.
>> With your patch #61 the UI will automatically renew the session, but if
>> the principal stays the same it won't execute the ipa_init again.
>>
>> I think the only thing that might change after session renewal is user
>> info (#2). The others are pretty much static. So we probably can move
>> whoami into another method that can be called separately.
>
> I agree this represents a good modification to the client logic however
> it don't see how it's specific to sessions. Wouldn't the same hold true
> for the current case when the principal changes?

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?

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?

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?

>> On top of your changes there would be some additional UI changes:
>>
>> 1. As described above, we need to move whoami out of ipa_init and call
>> it after each session renewal.
>> 2. The whoami output contains the user's authz info (group/role
>> membership). We need to redraw the UI components if the user's authz has
>> changed and make sure they are re-initialized correctly.
>> 3. We need to redirect the user to the UI main page if the current page
>> is no longer accessible due to authz changes.
>
> O.K. got it, here are my thoughts:
>
> 1) The enhanced logic is independent of sessions.
>
> 2) We need to test and exercise the new session auth so that code should
> be there.
>
> 3) However, adding the session logic in item 2 will be affected by the
> code changes in item 1.
>
> Therefore both should be done ASAP. We can either add the session code
> immediately and modify it later when the code changes in item 1 are done
> or put the session changes in immediately and modify it to use the new
> logic in item 1 when it's ready.
>
> I don't have strong feelings either way. However I would prefer if you
> or another UI guru made the changes you outline above rather than me. I
> think that would be more efficient and someone who intimately knows the
> UI code would be less likely to introduce a problem I might not be aware
> of.

I think the code that is already pushed is fine, except that we loses 
the backward compatibility, and your next patch will fix that. After 
that the above UI changes can be done separately by the UI team.

>>> The only thing which might be unaccounted for would be if the web UI for
>>> some reason wanted to use the old /ipa/json and not use sessions. It
>>> would need some extra logic to handle this but I don't see any need for
>>> this, after the server is updated to support sessions it sends back an
>>> ipa.js javascript file to the client which always elects to use the
>>> /ipa/session/json URL. If for some reason the browser is still using an
>>> old copy of ipa.js it simply ends up using the old /ipa/json URL without
>>> sessions, which should "just work".
>>
>> Right, no need to worry about this, the UI will just use one of the
>> methods.

On the second thought, after some discussions, we might want to support 
both cases in case a user cannot/would not use cookies. As long as both 
URL's are available, we can figure out later how the UI will use it.

> I do think we need a logout button which will invalidate the session
> auth. The current patch does not include an RPC command to accomplish
> that, but it's on my to-do list. Since we have to redo the patch to
> handle both session and non-session auth I could add that in at the same
> time (or we could open a new ticket and defer).

Here are the tickets, the logout URL can be added separately if you want:
https://fedorahosted.org/freeipa/ticket/2362
https://fedorahosted.org/freeipa/ticket/2363

-- 
Endi S. Dewata




More information about the Freeipa-devel mailing list