[Freeipa-users] FreeIPA Session Management (WebUI, Kerberos, ...?)

[Jan Pazdziora]

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