Re: [Freeipa-devel] [PATCH 61] Cache authentication in session
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/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 61] Cache authentication in session
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 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 61] Cache authentication in session
On 2/15/2012 2:51 AM, Dmitri Pal wrote: 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. I looked at the code briefly, if I understand correctly it looks like the server will get the session ID from the cookie and use it to find the existing session data from memcached. So if someone does a kinit to change principal, the browser will still send the same session ID because it doesn't know about the change, so the server will continue to use the old session with the old credentials until the session expires (which could be a long time if the server keeps resetting the expiration time). Previously without sessions the UI will detect the change as soon as the user executes another operation in the UI. 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. Assuming the principal will be stored in the cookie, it might not work because the browser will not know about the principal change so it's still sending the same principal. 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. Right now the key is just a 48-bit ID. 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. The question assumes that if the user changes principal he will get a new session, which doesn't seem to be the case. But suppose that issue is fixed, I agree that we need to make sure the old session is destroyed. 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. I believe John is going to make it 128-bit in the next patch. -- Endi S. Dewata ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 61] Cache authentication in session
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
Re: [Freeipa-devel] [PATCH 61] Cache authentication in session
On Wed, 2012-02-15 at 11:24 -0600, Endi Sukma Dewata wrote: 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. My preferred way would be to have it configurable, but I think 5 min. would be a reasonable compromise. 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, There is none without a Negotiate operation which we now do only when the session expires (hence my request for short expiration times). 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. Right, the old session is always destroyed. 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. ok 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 :) I know nobody, do you? :-) 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. Yes form based auth is just a leap of faith, you base all your security on the SSL connection, and there isn't much you can do beyond that. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 61] Cache authentication in session
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 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 61] Cache authentication in session
On 02/09/2012 12:16 AM, Endi Sukma Dewata wrote: On 2/8/2012 6:29 PM, John Dennis wrote: 1. For backward compatibility with curl or 3rd party apps, we should keep the existing authentication without session in /ipa/json and /ipa/xml. I originally wanted to use different URL's but was persuaded not to. I'm happy to see this recommendation, generally I think it's a good idea but see my caveat below. If I have any concern it's simply with the combinatoric matrix which has to be tested with this change. With something as critical as authentication having just one code path to validate has merit. But then again allowing both session and non-session based auth also has merit. Pick and choose your evils :-) Given we have already heavily tested the old mechanism I don't think there is too much risk in keeping it and just adding a new mechanism. Plus we will want handle form based auth soon and this adds yet another code path, so we probably should just be prepared to deal with the various combinations. Is there a way to use the same URLs to support both mechanisms? For example, can the client specify the mechanism to use in a request header, or some other tricks? If it's not possible I think we would have to use separate URLs and maintain backward compatibility. No. The URL is what tells us how the client is authenticating and which RPC mechanism they indent to use. The reason why the URL determines the auth method is because Apache enforces authentication based on a location i.e. a URL. This occurs before we see the request, in fact we won't even see the request unless Apache has validated the authentication. For sessions we don't use Apache based authentication, instead we leave the URL open without Apache authentication and perform the authentication inside the handler attached to the URL. It might be possible to fold the json and xmlrpc URL's into a single RPC URL if we could examine the request and determine the RPC mechanism from the data in the request but I don't see much advantage in this. We've actually been around this tree before with using different URL's and have concluded it's the only viable approach. Our choice is to either keep the existing URL's and introduce new incompatible behavior which was the decision we came to a few weeks back. Or we introduce new URL's, at the time the feeling was we wanted to keep the same URL's for location consistency sacrificing behavior consistency. Now we've reversed this decison which I'm O.K. with, but we can't have our cake and eat it too, we have to pick one or the other approach. We also want to tie the authorization to the sessions, so whenever the session expires the UI will reauthenticate using /ipa/login and then reload the authorization info in a separate operation using /ipa/session/json and then redraw the UI if necessary. This way we can keep the /ipa/login generic enough to be used by both XML and JSON clients. Unless I've misunderstood, the existing code pretty much does this already, albeit with different URL's. Aside from adjusting the URL's was there something else you were looking for? 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? Bottom line, it's a good optimization which should be done but it seems independent of the session work. In other words, the UI needs to be changed so that during initial load the UI should do ipa_init and whoami, and after each session renewal it should only do the whoami only. Just to be clear, here is the sequence of operations: Client sends post to /ipa/session/json (or /ipa/session/xml). (This could be the first post for which there is no existing session or a post after the session has expired, it doesn't matter which case it is) Server responds with auth failure (and session cookie) Client sends GET to /ipa/login along with session cookie which refreshes credentials in session (or fails because the credentials could not be refreshed, in which case this is treated as a hard error and processing stops on the client signaling an error to the user)
Re: [Freeipa-devel] [PATCH 61] Cache authentication in session
Endi Sukma Dewata wrote: On 2/6/2012 12:35 PM, John Dennis wrote: rebased because patch 61-2 did not apply to master. I've looked at the ipa.js, attached is a patch that fixes several issues: 1. The error_handler_login() does nothing if it gets an error other than 401, it was causing the unit tests to fail. It's supposed to call the original error_handler(). 2. In line 62 the login_url is not needed for the other case because I don't think we can generate error 401 with the test data. 3. There were some jslint warnings in line 312 and 424, it's missing a semi colon at the end of the line. 4. It replaces the tabs used for indentation with spaces in IPA.get_credentials(). Feel free to merge this patch into yours or apply it separately. I found some other issues but it probably can be addressed separately: 5. If the ipa_memcached is restarted (to simulate session expiration), subsequent UI operations will generate the 'Kerberos ticket no longer valid' error dialog. After about 45 seconds it will work again. Ideally the users should not see this. I'm not sure if a similar situation will happen when the session times out in a normal situation. 6. The curl command like in install/ui/test/bin/update_ipa_init.sh will not work anymore because it doesn't use session. We need to figure out how to enable sessions on curl. ACK for John's patch with Endi's revision. There will still be some clean up and changes to do but lets go ahead and get this in, the rest is just fine tuning. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 61] Cache authentication in session
On 2/9/2012 12:12 PM, Rob Crittenden wrote: ACK for John's patch with Endi's revision. Pushed to master and ipa-2-2. -- Endi S. Dewata ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 61] Cache authentication in session
John, Per discussion with Rob, Simo, and Adam we're considering to make these changes: 1. For backward compatibility with curl or 3rd party apps, we should keep the existing authentication without session in /ipa/json and /ipa/xml. 2. For the UI we can use the sessions using different URIs: * /ipa/login for authentication * /ipa/session/json for the actual operations 3. If we modify the CLI later to use the sessions it will use the following URIs: * /ipa/login for authentication * /ipa/session/xml for the actual operations Is this OK? How difficult is it to make the above changes? We also want to tie the authorization to the sessions, so whenever the session expires the UI will reauthenticate using /ipa/login and then reload the authorization info in a separate operation using /ipa/session/json and then redraw the UI if necessary. This way we can keep the /ipa/login generic enough to be used by both XML and JSON clients. I think the UI changes can be done separately, I'll open the tickets. -- Endi S. Dewata ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 61] Cache authentication in session
On 02/08/2012 03:23 PM, Endi Sukma Dewata wrote:
John,
Per discussion with Rob, Simo, and Adam we're considering to make these
changes:
1. For backward compatibility with curl or 3rd party apps, we should
keep the existing authentication without session in /ipa/json and /ipa/xml.
I originally wanted to use different URL's but was persuaded not to. I'm
happy to see this recommendation, generally I think it's a good idea but
see my caveat below.
If I have any concern it's simply with the combinatoric matrix which has
to be tested with this change. With something as critical as
authentication having just one code path to validate has merit. But then
again allowing both session and non-session based auth also has merit.
Pick and choose your evils :-) Given we have already heavily tested the
old mechanism I don't think there is too much risk in keeping it and
just adding a new mechanism. Plus we will want handle form based auth
soon and this adds yet another code path, so we probably should just be
prepared to deal with the various combinations.
2. For the UI we can use the sessions using different URIs:
* /ipa/login for authentication
* /ipa/session/json for the actual operations
3. If we modify the CLI later to use the sessions it will use the
following URIs:
* /ipa/login for authentication
* /ipa/session/xml for the actual operations
Is this OK? How difficult is it to make the above changes?
Yes it's OK. I don't think it will be terribly difficult. We register
RPC handlers for each URL in the server. It would require adding new
handlers. But I suspect some of the code in the duplicated handlers
would be identical and I'm not a fan of cut-n-paste code logic, I'd
rather see things call into common code. So although duplicating the
handlers would be straight forward and quick we might want to refactor
some logic to keep duplication to a minimum so we only differ in the
actual auth logic in the handlers but otherwise share common code to
dispatch the RPC in the handler. My estimate would be 1-2 days of work
to recode and test depending on the extent of any necessary refactoring.
We also want to tie the authorization to the sessions, so whenever the
session expires the UI will reauthenticate using /ipa/login and then
reload the authorization info in a separate operation using
/ipa/session/json and then redraw the UI if necessary. This way we can
keep the /ipa/login generic enough to be used by both XML and JSON clients.
Unless I've misunderstood, the existing code pretty much does this
already, albeit with different URL's. Aside from adjusting the URL's was
there something else you were looking for?
Just to be clear, here is the sequence of operations:
Client sends post to /ipa/session/json (or /ipa/session/xml). (This
could be the first post for which there is no existing session or a post
after the session has expired, it doesn't matter which case it is)
Server responds with auth failure (and session cookie)
Client sends GET to /ipa/login along with session cookie which refreshes
credentials in session (or fails because the credentials could not be
refreshed, in which case this is treated as a hard error and processing
stops on the client signaling an error to the user)
Presuming the credential refresh succeeded the client resends the
previous post that failed due to insufficient auth (along with session
cookie) to /ipa/session/{json,xml} which now succeeds because session is
populated with valid credentials from the previous step. From the user's
perspective nothing is different other than a possible delay due to the
extra protocol exchanges occurring under the covers.
Note: for the json case there is no need to reload the UI unless the
previous principal does not match the current principal (i.e. switch
user). To the best of my knowledge the existing code already handles
this case.
I think the UI changes can be done separately, I'll open the tickets.
Not sure I see the need for new tickets, could you elaborate? I think
the UI code pretty much already does what we want, it just needs to be
tweaked a bit for the URL changes. That small adjustment can be handled
in the updated patch.
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.
Let me know your thoughts.
--
John Dennis jden...@redhat.com
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/
___
Freeipa-devel mailing list
Re: [Freeipa-devel] [PATCH 61] Cache authentication in session
On 2/8/2012 6:29 PM, John Dennis wrote:
1. For backward compatibility with curl or 3rd party apps, we should
keep the existing authentication without session in /ipa/json and
/ipa/xml.
I originally wanted to use different URL's but was persuaded not to. I'm
happy to see this recommendation, generally I think it's a good idea but
see my caveat below.
If I have any concern it's simply with the combinatoric matrix which has
to be tested with this change. With something as critical as
authentication having just one code path to validate has merit. But then
again allowing both session and non-session based auth also has merit.
Pick and choose your evils :-) Given we have already heavily tested the
old mechanism I don't think there is too much risk in keeping it and
just adding a new mechanism. Plus we will want handle form based auth
soon and this adds yet another code path, so we probably should just be
prepared to deal with the various combinations.
Is there a way to use the same URLs to support both mechanisms? For
example, can the client specify the mechanism to use in a request
header, or some other tricks? If it's not possible I think we would have
to use separate URLs and maintain backward compatibility.
We also want to tie the authorization to the sessions, so whenever the
session expires the UI will reauthenticate using /ipa/login and then
reload the authorization info in a separate operation using
/ipa/session/json and then redraw the UI if necessary. This way we can
keep the /ipa/login generic enough to be used by both XML and JSON
clients.
Unless I've misunderstood, the existing code pretty much does this
already, albeit with different URL's. Aside from adjusting the URL's was
there something else you were looking for?
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.
In other words, the UI needs to be changed so that during initial load
the UI should do ipa_init and whoami, and after each session renewal it
should only do the whoami only.
Just to be clear, here is the sequence of operations:
Client sends post to /ipa/session/json (or /ipa/session/xml). (This
could be the first post for which there is no existing session or a post
after the session has expired, it doesn't matter which case it is)
Server responds with auth failure (and session cookie)
Client sends GET to /ipa/login along with session cookie which refreshes
credentials in session (or fails because the credentials could not be
refreshed, in which case this is treated as a hard error and processing
stops on the client signaling an error to the user)
Presuming the credential refresh succeeded the client resends the
previous post that failed due to insufficient auth (along with session
cookie) to /ipa/session/{json,xml} which now succeeds because session is
populated with valid credentials from the previous step. From the user's
perspective nothing is different other than a possible delay due to the
extra protocol exchanges occurring under the covers.
Note: for the json case there is no need to reload the UI unless the
previous principal does not match the current principal (i.e. switch
user). To the best of my knowledge the existing code already handles
this case.
Right.
I think the UI changes can be done separately, I'll open the tickets.
What I meant here is that since we're keeping backward compatibility you
don't really have to modify the UI in the same patch because it will
still work like before. Your UI changes with the patch that I sent in
the earlier email would be good enough to push, but if you decide to
delay it to make additional changes it should be fine too.
Not sure I see the need for new tickets, could you elaborate?
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.
I think
the UI code pretty much already does what we
Re: [Freeipa-devel] [PATCH 61] Cache authentication in session
On 02/05/2012 06:56 PM, John Dennis wrote: On 01/25/2012 09:16 AM, Rob Crittenden wrote: John Dennis wrote: On 01/23/2012 06:15 PM, John Dennis wrote: Rebased patch attached (includes contents of previous patch 60). The issues with ipa_memcached belonged to patch 59, that patch was rebased and resubmitted. I cannot reproduce the looping problem you saw. The only thing I can think of is that you were running with SELinux enabled and currently ipa_memcached requires SELinux to be disabled otherwise the whole caching mechanism fails. O.K., let's try this again with the patch actually attached :-) NACK. It doesn't work if ipa_memcached is not configured (-M install option). I tested this last night then picked up testing again this morning and was greeted with the attached image. I'm not sure if this is a browser issue, the fact that my browser was being redirected from a VM to the display on my desktop or the current cosmic rays. We also need a way to do a logout. The user can do a kdestroy and still have an active session. If this isn't covered in the any current tickets please open a new one. As far as I can tell you provide a facility for invalidating a cache entry, I'm just not sure if that is enough for the UI guys to hook in to. I think you were right about SELinux. When I put it into permissive mode then the caching worked. The UI is much more responsive now. Attached is a modified patch. The logic concerning how Kerberos auth is acquired was modified, we no longer use redirects. Instead we return an error and the javascript code in the browser sends a GET to the login page to refresh the session credentials. If that succeeds it resubmits the POST that previously was denied. This works much better, no longer are there any browser glitches, it seems to function very smoothly with good performance. I also added a config item, session_auth_duration so that admins can control how long a session will be valid before credentials need to be refreshed. The default.config man page was updated to document the new option. It's easy to specify using simple notation such as 1 hour, 30 minutes or 1h30m, etc. I added a new utility parse_time_duration() to read the duration specification. I also modified how files were being used to for the Kerberos ccache. The previous code allocated one file per session, but there wasn't a good way to clean up these files. Now there is just one ccache file per process and it only exists for the duration of the request after which we remove it. The ccache is stored in the memcached session data. We refresh the memcached copy of the ccache at the end of the request to make sure any credentials modified/added during the request are preserved. The submit comments reasonably detailed, you should take a look at those for more information. Forgot two things: The server install and run must be done with SELinux in permissive mode, we still don't have an updated policy for ipa_memcached. I also modified how I was validating the ticket. Now I check either the TGT or the ldap service ticket, formerly it had just been the TGT. This was changed to accommodate s4u2proxy, which I tried to test with but I'm not sure it was in effect despite having what I believe was updated packages installed. -- John Dennis jden...@redhat.com Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 61] Cache authentication in session
On Wed, 2012-01-25 at 09:16 -0500, Rob Crittenden wrote: John Dennis wrote: On 01/23/2012 06:15 PM, John Dennis wrote: Rebased patch attached (includes contents of previous patch 60). The issues with ipa_memcached belonged to patch 59, that patch was rebased and resubmitted. I cannot reproduce the looping problem you saw. The only thing I can think of is that you were running with SELinux enabled and currently ipa_memcached requires SELinux to be disabled otherwise the whole caching mechanism fails. O.K., let's try this again with the patch actually attached :-) NACK. It doesn't work if ipa_memcached is not configured (-M install option). I tested this last night then picked up testing again this morning and was greeted with the attached image. I'm not sure if this is a browser issue, the fact that my browser was being redirected from a VM to the display on my desktop or the current cosmic rays. We also need a way to do a logout. The user can do a kdestroy and still have an active session. If this isn't covered in the any current tickets please open a new one. As far as I can tell you provide a facility for invalidating a cache entry, I'm just not sure if that is enough for the UI guys to hook in to. I think you were right about SELinux. When I put it into permissive mode then the caching worked. The UI is much more responsive now. We definitely need a ticket to add a Log Out button. It is nice when you can log out even if you haven't destroyed your credentials. May be used by a normal user to go to the form based login to login as admin w/o having to kinit admin first in the future. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 61] Cache authentication in session
On 01/17/2012 04:37 PM, Rob Crittenden wrote: John Dennis wrote: Both of these are defined in ipalib/rpc.py (among others): +KRB5_CC_NOTFOUND = -1765328243 # Matching credential not found +KRB5_FCC_NOFILE = -1765328189 # No credentials cache found Perhaps all those defines should be moved to krb_utils.py. RPM build errors on non-SysV systems: File listed twice: /usr/share/ipa/ui/extension.js Installed (but unpackaged) file(s) found: /etc/rc.d/init.d/ipa_memcached make: *** [rpms] Error 1 (extention.js isn't yours) In the ipa_memcached service PID_PATH needs to be PIDFILE. It would be nice if sessions worked with the lite-server. I am unable to view the web UI. It just loops requesting all the the javascript files over and over again. rob Rebased patch attached (includes contents of previous patch 60). The issues with ipa_memcached belonged to patch 59, that patch was rebased and resubmitted. I cannot reproduce the looping problem you saw. The only thing I can think of is that you were running with SELinux enabled and currently ipa_memcached requires SELinux to be disabled otherwise the whole caching mechanism fails. -- John Dennis jden...@redhat.com Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 61] Cache authentication in session
John Dennis wrote: Both of these are defined in ipalib/rpc.py (among others): +KRB5_CC_NOTFOUND = -1765328243 # Matching credential not found +KRB5_FCC_NOFILE = -1765328189 # No credentials cache found Perhaps all those defines should be moved to krb_utils.py. RPM build errors on non-SysV systems: File listed twice: /usr/share/ipa/ui/extension.js Installed (but unpackaged) file(s) found: /etc/rc.d/init.d/ipa_memcached make: *** [rpms] Error 1 (extention.js isn't yours) In the ipa_memcached service PID_PATH needs to be PIDFILE. It would be nice if sessions worked with the lite-server. I am unable to view the web UI. It just loops requesting all the the javascript files over and over again. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
