On Wed, Aug 10, 2016 at 5:27 AM, Jan Pazdziora <jpazdzi...@redhat.com> wrote:
> On Tue, Aug 09, 2016 at 03:37:35PM -0400, Joe Thielen wrote: > > > > For example, let's say "joe" logs in to the WebUI (OR another web app > tied > > to FreeIPA). Now, on another computer, "admin" logs into the WebUI. Can > > admin have a way to see that "joe" logged in, and, if need be, kill Joe's > > session? > > Typical Web applications handle sessions via HTTP cookies. You might > have additional cookies added by other layers, like mod_auth_mellon > for SAML, but one your typical PHP application sees the user > (externally) authenticated, it will create its own session as well, > signed, and that's what it will use. The only party which has access > to that session is user's browser, plus of course it is recorded in > the application database. > > You will likely not find a generic mechanism which would allow you to > log out random application-level session (cookie-based) because after > all, it is not FreeIPA that created the session -- it's the > application. And even if FreeIPA was creating the sessions, > applications would be creating their own and those would still stay > around and be valid. > > Your best bet might be to make the application-level session lifetime > reasonably short, to force reauthentication at regular intervals. If > some form of single sign-on authentication happens where the user is > not asked for their creentials again, you will get check with the > central authority (which can then block authentication attempt for > user that was made disabled) without user's workflow being disrupted > too much. > > By the way -- you say "Joe's session". I assume you will only do that > when at the same time Joe should not be able to reauthenticate again > to that service, right? > > > I guess I'm running in circles because then again I think... "what about > > pure Kerberos" clients... > > Pure Kerberos clients are another fun -- the whole Kerberos > authentication is built around the time-based service tickets. If the > client already has a service ticket for the service, it does not need > to consult KDC, and neither is the central authority consulted by the > Web applications -- they trust the service tickets that they are able > to decrypt. > > > or those using intercept_form_submit_module? > > I'm not familiar with PAM. > > Well, PAM access phase might actually be a good way to be able to > "plug in" authorization check to Web accesses. That way even if > authentication (proof of identity) is done via method that does not > contact central server (Kerberos), the authorization can happen > against central authority. You can check > > https://www.adelton.com/apache/mod_authnz_pam/ > > for example of adding PAM-based authorization to GSS-API > authentication. And mod_intercept_form_submit does the same, for > username+password authentication. > > But as noted above, this will just affect the Apache-based > authentication / authorization and will prevent the application session > from being created. It will not play any role in application-level > session where the cookie is hold by the browser and evaluated by the > application directly. > > -- > Jan Pazdziora > Senior Principal Software Engineer, Identity Management Engineering, Red > Hat > Jan, thanks for the insights. I realize that once the auth takes place and the cookie is set that an external entity (a centralized session manager) can't do much about the cookie. My expectation is the web app (server-side, not client-side) will have to "phone home" to the centralized session manager on each request to ensure the session is still valid. If the web app gets a signal that the session is no longer valid, and it must not be renewed, then it would end it's own session and no longer allow the user to continue. And yes, you are correct in regards to "Joe's session", he would not be allowed to re-authenticate. This will certainly increase overhead, but I'm looking at it from a security perspective more than anything else. Having a short session span makes sense, forcing frequent automatic re-authentication. This would help in situations when using a 3rd party web app which doesn't meet the expectation that it'd be phoning home on each request. Now that I'm thinking about this more, I wonder if it'd be easier to turn this around the other way. Instead of the web app phoning home on each request to check and see if the session is still valid (lot's of overhead to check for something that may very rarely happen), and maybe have a way for the centralized session manager to instead talk to the web app server and initiate the killing of the session that way. So this could actually be made as a custom plugin for 3rd party apps too... a way to remotely kill sessions. An example of this would be a FreeIPA WebUI session. If the memcached record for the session were deleted by a 3rd party, that would cause their session to end, right? A little brutal, but effective. Of course it'd also have to mark the user as disabled otherwise they could just re-auth. This would all depend on getting the login info from the auth phase to the centralized session manager in the first place... i.e., the fact that a session was established and exists. But you already gave me some hints for that, possibly via PAM. Thanks for responding and letting me look at this from different angles.
-- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
