From config/initializers/1_settings.rb in the GitLab repo:

Settings.omniauth['providers'] ||= []
Settings.omniauth['cas3'] ||= Settingslogic.new({})
Settings.omniauth.cas3['session_duration'] ||= 8.hours
Settings.omniauth['session_tickets'] ||= Settingslogic.new({})
Settings.omniauth.session_tickets['cas3'] = 'ticket'

Looks like the default is 8 hours.

irb(main):003:0> 8.hours.to_s
=> "28800"

I'll try with a value of 604800 on the test box and see what happens.

On further investigation, I don't think gitlab_rails['omniauth_cas3_session_duration'] is getting applied; the 8 hour default seems to remain regardless. After some experimentation, I haven't figured out how to override the value here:

rb(main):003:0> Settings.omniauth.cas3
=> {"session_duration"=>8 hours}

(See P17017 for full Settings.omniauth.)

I've tried placing the session_duration value inside args, in omniauth_providers[0], etc. Structurally, I think this is the right idea:

gitlab_rails['omniauth_cas3'] = {
    "session_duration" => 604800
}

gitlab_rails['omniauth_providers'] = [
  {
      "name" => "cas3",
      "label" => "cas",
      "args" => {
          "url" => 'https://idp.wmcloud.org',
          "login_url" => '/login',
          "service_validate_url" => '/p3/serviceValidate',
          "logout_url" => '/logout',
      }
  }
]

...since cas3 is a top-level value within omniauth, but that doesn't seem to have any effect. Neither does:

gitlab_rails['omniauth'] = {
    "cas3" => {
        "session_duration" => '604800'
    }
}

Looking at gitlab.yml.erb in the omnibus-gitlab repo, I think setting the cas3 session_duration isn't actually supported from gitlab.rb.

The omnibus docs on changing gitlab.yml and application.yml settings:

Note that not all gitlab.yml settings can be changed via gitlab.rb yet; see the gitlab.yml.erb template. If you think an attribute is missing please create a merge request on the Omnibus GitLab repository.

Working up a patch for that.

cc: @jbond and @Jelto for awareness re: CAS session lifetimes, and in case I'm missing something obvious.

Upstream merge request: https://gitlab.com/gitlab-org/omnibus-gitlab/-/merge_requests/5558

@brennen i have had a look at this today and i can't recreate the issue. however it is worth noting that when you login to the cas portal you must set the remember me check box to have a log session (7 days) otherwise the session is set to one hour (which sounds like what you may be hitting). The session handling of cas is documented further on the wiki

Hmm - yeah, it's possible that either:

• People aren't checking the "remember me" box.
• They are checking it but are still shown the signed out state and are getting the 2FA prompt in a shorter timeframe - I just experienced this but I can't say whether I had checked "remember me" previously or not.

To follow up:

• I logged in yesterday at 10:30am local, with "remember me" checked
• Checked around 10pm local and was prompted for a 2FA code, but did not receive a login form
• Checked just now (a bit over 24 hours later), and I appear to be signed out altogether. Clicking "Sign in", however, takes me to https://gitlab.wikimedia.org/users/auth/cas3/callback?url=https%3A%2F%2Fgitlab.wikimedia.org%2Fexplore&ticket=[redacted] rather than the IDP sign-in form.

I polled RelEng folks during our team meeting this morning, and from 6 responses the consensus generally seems to be that people are sent to the IDP login after ~1 day, regardless of "remember me" checkbox. It's possible that in some cases users are just seeing the apparently fully logged-out state and assuming they'll have to enter username & password again.

@brennen i was also able to recreate this. When you login via CAS SSO, we create a TGT which last for 7 days (assuming remember me was ticked), The CAS client (gitlab in this case) will then create a local session, when using mod_auth_cas the local session last for 2 hours it seems gitlab has a default of 8 hourse. When this expires the user is automatically redirected to the cas portal (idp.w.o) and assuming there global sso session is still valid they will be logged in automatically.

I think that what is happening with gitlab is that the local session expires, a redirect occurs and assuming that 2fa is not enabled for the account then the user will be seamlessly logged in. however if 2fa is enabled then when gtilab refreshes the session it receives an authorisation from cas idp but also needs to request the second factor authentication from the user. One way to fix this would be to have users configure 2FA in cas and not gitlab itself (however this process is not very accessible). I think the other options is exactly what you have highlighted above i.e. increase the local gitlab session timeout

I think the other options is exactly what you have highlighted above i.e. increase the local gitlab session timeout

Seems reasonable. The ability to configure this in omnibus has merged upstream. I'm not sure if anything's needed to get into the next patch release for the 13.x line but I've asked the reviewer on that. In the meanwhile, I'll try setting the value directly and if that works we can put a shim in place for dropping it in with sed when reconfiguring.

In T288757#7312240, @brennen wrote:

I think the other options is exactly what you have highlighted above i.e. increase the local gitlab session timeout

Seems reasonable. The ability to configure this in omnibus has merged upstream.

nice that was quick :)

I'm not sure if anything's needed to get into the next patch release for the 13.x line but I've asked the reviewer on that. In the meanwhile, I'll try setting the value directly and if that works we can put a shim in place for dropping it in with sed when reconfiguring.

Feel free to add me to any CR some hacks may be nicer then others ;)

Feel free to add me to any CR some hacks may be nicer then others ;)

Will do!

Looks like there probably won't be any further 13.x patch releases; added T289802 for thinking about our 14.x upgrade.

Something like this works, just needs to run after anything that runs the Chef reconfiguration stuff. Not quite sure where to hang it:

#!/bin/bash

GITLAB_YML=/opt/gitlab/embedded/service/gitlab-rails/config/gitlab.yml

if ! grep -q 'session_duration' "$GITLAB_YML"; then
  # No session_duration value, use sed to append it in the omniauth section:
  sed -i '/^  omniauth:/ a  \    cas3: { session_duration: 604800 }' "$GITLAB_YML"
fi

...anyway, I've got that value in place on gitlab1001, will see if it improves user experience.

Change 722682 had a related patch set uploaded (by Brennen Bearnes; author: Brennen Bearnes):

[operations/gitlab-ansible@master] set session lifetime to 604800s (1w)

https://gerrit.wikimedia.org/r/722682

Change 728618 had a related patch set uploaded (by Brennen Bearnes; author: Brennen Bearnes):

[operations/puppet@production] gitlab: set session duration to 604800 seconds

https://gerrit.wikimedia.org/r/728618

Change 728618 merged by Dzahn:

[operations/puppet@production] gitlab: set session duration to 604800 seconds

https://gerrit.wikimedia.org/r/728618

Change 722682 abandoned by Hashar:

[operations/gitlab-ansible@master] set session lifetime to 604800s (1w)

Reason:

the configuration has been moved to Puppet in the gitlab module.

https://gerrit.wikimedia.org/r/722682