Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-47767

kerberos sso sessions are not renewed automatically

XMLWordPrintable

      It seems that Kerberos sessions are not renewed automatically and we need to relogin at least daily if not multiple times a day.

      I am used 4-5 jenkins servers and multiple browsers and being downgraded to anonymous is a really PITA which I wish I could avoid. 

      Is not a very big deal to click again the login button but it would be much better if we would not have to do this so often. If I would have to do it every week it would ok, but not multiple times per day. 

      Imagine Google Auth, I think last time I had to login to google was few months ago, why do I need to do it more often on Jenkins?

          [JENKINS-47767] kerberos sso sessions are not renewed automatically

          Sorin Sbarnea added a comment -

          olivergondza, do you know what we need to do to address this?

          Sorin Sbarnea added a comment - olivergondza , do you know what we need to do to address this?

          Oliver Gondža added a comment - - edited

          There are (at least) 2 things in play here:

          • sessionTimeout attribute determining how long would Jenkins remember you have authenticated
          • and kerberos-sso plugin not re-authenticating proactively when you have valid tgt ticket but Jenkins session has already expired.

          The most straightforward way to go here is to extend the session timeout on given deployments. If we would like to treat the users with kerberos ticket specially in this plugin, there is a problem to crack first (note even JIRA kerberos support does not re-authenticate you until you click the Log In button).

          The problem is the client is not making server aware it has a ticket for the service (or it can get it using tgt - which it has no way of knowing until it tries contacting kdc) until it received 401 reply permitting to negotiate authentication (so even the client have no idea if the server supports kerberos or not). Serving 401 is exactly what the anonymous mode prevents so unauthenticated users can get in. I guess we can try serving invisible iframe with login page in so when you access Jenkins after session expiration you will still get unauthenticated page but all followup requests will be authenticated (if negotiation went well) so you might not even notice if you are lucky enough.

          Oliver Gondža added a comment - - edited There are (at least) 2 things in play here: sessionTimeout attribute determining how long would Jenkins remember you have authenticated and kerberos-sso plugin not re-authenticating proactively when you have valid tgt ticket but Jenkins session has already expired. The most straightforward way to go here is to extend the session timeout on given deployments. If we would like to treat the users with kerberos ticket specially in this plugin, there is a problem to crack first (note even JIRA kerberos support does not re-authenticate you until you click the Log In button). The problem is the client is not making server aware it has a ticket for the service (or it can get it using tgt - which it has no way of knowing until it tries contacting kdc) until it received 401 reply permitting to negotiate authentication (so even the client have no idea if the server supports kerberos or not). Serving 401 is exactly what the anonymous mode prevents so unauthenticated users can get in. I guess we can try serving invisible iframe with login page in so when you access Jenkins after session expiration you will still get unauthenticated page but all followup requests will be authenticated (if negotiation went well) so you might not even notice if you are lucky enough.

            olivergondza Oliver Gondža
            ssbarnea Sorin Sbarnea
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated: