Re: [Freeipa-users] FreeIPA Session Management (WebUI, Kerberos, ...?)
> Date: Wed, 10 Aug 2016 09:02:29 +0200 > From: Petr Spacek > To: freeipa-users@redhat.com > Subject: Re: [Freeipa-users] FreeIPA Session Management (WebUI, > Kerberos, ...?) > Message-ID: > Content-Type: text/plain; charset=windows-1252 > > On 9.8.2016 21:37, Joe Thielen wrote: > > First off, let me say THANK YOU to all of you who've helped make FreeIPA > > what it is. I think it's a fantastic project and it's amazing what it > has > > achieved. > > > > Second off, I'm still quite new to FreeIPA, especially the internals. > This > > includes Kerberos. I'm also very very limited at Python (I come from a > PHP > > background - please don't hold it against me). I have toyed around with > > LDAP a little bit before looking at FreeIPA. > > > > After re-reading this e-mail I think it'd be important to note here at > the > > top that my focus is on web-based apps and non-kerberized clients. The > web > > app server would be an IPA client. I don't foresee a lot of > terminal-based > > stuff going on, aside from potential admin CLI tasks (for the web-based > > app). > > > > I apologize in advance for the length of this e-mail. I have searched, a > > lot, to try and answer my own questions. That's actually how I found > > FreeIPA in the first place. I've looked at the site/wiki, the mailing > list > > archive, and the Internet in general. But I've been unable to find a > > solution, or suggestions, which achieves exactly what I'm looking for. > It > > may be that I'm just using the wrong terminology and/or getting lost in > the > > buzzwords. > > > > What I'm trying to figure out is if there is a way to centrally manage > > sessions, in addition to everything else FreeIPA currently does. I'm not > > necessarily just talking about WebUI sessions, I'd like external web apps > > to be able to make use of it too. And, I'd like to be able to manage > them > > via the WebUI. > > > > 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? > > > > I'd like for it to maintain history. For each login/session, I'd like to > > see who logged in, when, from where, what their last access was, when > they > > logged out (or if their session timed out), and the logout reason (manual > > logout, session timeout, or admin intervention). > > > > But like I said, I'm not just looking for WebUI sessions. > > > > Let's say I create a web app. I put it on a machine which is an IPA > > client. Thanks to the wealth of documentation and options, I have a > > variety of methods to achieve authentication. FreeIPA makes this great, > > and for that I'm thankful. However, in most of the documentation, it > just > > says "create the session" cookie, and the rest is left as an exercise to > > the reader. I'm familiar with web apps and have implemented session > > management before. What I'd love to see is FreeIPA to be able to handle > > not just the auth but also the session management. > > > > Why? Because I'd not like to have to re-invent the wheel. And I'm > trying > > to see if there is already some method to do this that I'm just > > fundamentally missing. Or at least if there are enough pieces that I > could > > put together to make it happen. > > > > For "fun", I've tried to set up auth using different methods. I've > > successfully set it up using intercept_form_submit_module and > > lookup_identity_module. That's pretty neat, works great for auth. But, > as > > far as I can tell, this method doesn't create a session or login trail in > > the memcached DB. In fact, I can't really find any trail aside from the > > Kerberos logging messages in /var/log/krbkdc.log. > > > > I've also used Tobias Sette's php-freeipa from GitHub. That works great > > too... for auth. And since that uses the JSON API, it looks like it does > > create a record in the memcached DB. So I suppose this could be one way > > in, maybe by a FreeIPA plugin? > > > > I guess I'm running in circles because then again I think... "what about > > pure Kerberos" clients... or those using intercept_form_submit_module? > > I&#
Re: [Freeipa-users] FreeIPA Session Management (WebUI, Kerberos, ...?)
On Wed, Aug 10, 2016 at 5:27 AM, Jan Pazdziora 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.
Re: [Freeipa-users] FreeIPA Session Management (WebUI, Kerberos, ...?)
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 -- 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
Re: [Freeipa-users] FreeIPA Session Management (WebUI, Kerberos, ...?)
On 9.8.2016 21:37, Joe Thielen wrote: > First off, let me say THANK YOU to all of you who've helped make FreeIPA > what it is. I think it's a fantastic project and it's amazing what it has > achieved. > > Second off, I'm still quite new to FreeIPA, especially the internals. This > includes Kerberos. I'm also very very limited at Python (I come from a PHP > background - please don't hold it against me). I have toyed around with > LDAP a little bit before looking at FreeIPA. > > After re-reading this e-mail I think it'd be important to note here at the > top that my focus is on web-based apps and non-kerberized clients. The web > app server would be an IPA client. I don't foresee a lot of terminal-based > stuff going on, aside from potential admin CLI tasks (for the web-based > app). > > I apologize in advance for the length of this e-mail. I have searched, a > lot, to try and answer my own questions. That's actually how I found > FreeIPA in the first place. I've looked at the site/wiki, the mailing list > archive, and the Internet in general. But I've been unable to find a > solution, or suggestions, which achieves exactly what I'm looking for. It > may be that I'm just using the wrong terminology and/or getting lost in the > buzzwords. > > What I'm trying to figure out is if there is a way to centrally manage > sessions, in addition to everything else FreeIPA currently does. I'm not > necessarily just talking about WebUI sessions, I'd like external web apps > to be able to make use of it too. And, I'd like to be able to manage them > via the WebUI. > > 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? > > I'd like for it to maintain history. For each login/session, I'd like to > see who logged in, when, from where, what their last access was, when they > logged out (or if their session timed out), and the logout reason (manual > logout, session timeout, or admin intervention). > > But like I said, I'm not just looking for WebUI sessions. > > Let's say I create a web app. I put it on a machine which is an IPA > client. Thanks to the wealth of documentation and options, I have a > variety of methods to achieve authentication. FreeIPA makes this great, > and for that I'm thankful. However, in most of the documentation, it just > says "create the session" cookie, and the rest is left as an exercise to > the reader. I'm familiar with web apps and have implemented session > management before. What I'd love to see is FreeIPA to be able to handle > not just the auth but also the session management. > > Why? Because I'd not like to have to re-invent the wheel. And I'm trying > to see if there is already some method to do this that I'm just > fundamentally missing. Or at least if there are enough pieces that I could > put together to make it happen. > > For "fun", I've tried to set up auth using different methods. I've > successfully set it up using intercept_form_submit_module and > lookup_identity_module. That's pretty neat, works great for auth. But, as > far as I can tell, this method doesn't create a session or login trail in > the memcached DB. In fact, I can't really find any trail aside from the > Kerberos logging messages in /var/log/krbkdc.log. > > I've also used Tobias Sette's php-freeipa from GitHub. That works great > too... for auth. And since that uses the JSON API, it looks like it does > create a record in the memcached DB. So I suppose this could be one way > in, maybe by a FreeIPA plugin? > > I guess I'm running in circles because then again I think... "what about > pure Kerberos" clients... or those using intercept_form_submit_module? > I'm not familiar with PAM. But from what I can tell, I assume there is a > way to add a "pluggable" module for it too. But on the server? i.e., if a > Kerberos session is established, is there a way, via PAM (or something > else?) to log that session to the FreeIPA server? I think this is kinda > what Kerberos is trying to get away from, but for the use cases I'm > thinking of, it'd be a big feature. In my searching I've seen things like > nss_mysql which look interesting, but of course wouldn't mesh with the > FreeIPA WebUI memcached method. > > Speaking of which, I know that memcached is not by any means a permanent > session log, and I understand it's not intended to be. So would this go > into the LDAP tree? Would this clog it up too much? I'm looking to store > a year of info... or more depending on the scenario. > > I've briefly looked at the Apache Shiro project. I'm not a Java guy, but > from I'm reading it kind of has the right idea. It even notes that the > session management portions can be accessed from other apps (on other > machines) and not necessarily from Java. But due to the whole thing being > a mostly-J
