fedora-infrastructure

#11573 [GitLab] Tell the SSO auth to chill out
Closed: Will Not/Can Not fix by phsmoura. Opened by jflory7.

Closed: Will Not/Can Not fix
Reopen Issue

Describe what you would like us to do:

The Fedora organization on GitLab is very aggressive about users re-authenticating with SSO any time they interact with the Fedora GitLab org. This happens not just with settings dialogues and private issues, but also with things that are public to all GitLab users, e.g. public issues and Merge Requests.

I hypothesize this is a collaboration friction point with using GitLab. Even for my own account, I re-authenticate multiple times a day when viewing or commenting on GitLab issues in the Fedora org. Sometimes I lose content that I have drafted or lose a tab that I was keeping open when I get prompted for SSO login, but I discover the login prompt long after the request expires.

I want to better understand how much exactly this is something we can control. If it is something we can control, could we choose a more sane default, like once every other week? If it is not something we directly control, is there any way that we could work with GitLab to make this SSO re-authentication less aggressive?

When do you need this to be done by?

It depends on how much is required to accomplish this? I don't know if this is a setting we can control or not. If it is a hypothetical twisting of a control knob, then as soon as possible.

CC: @nb

The only thing I can find is:

"Users are not prompted to sign in through SSO on each visit. GitLab checks whether a user has authenticated through SSO. If the user last signed in more than 24 hours ago, GitLab prompts the user to sign in again through SSO."

But it sounds like you are seeing many more times than once a day. ;(

Perhaps @sgallagh has heard something here?

We have seen a similar issue for some of our European colleagues in the RHEL namespace on gitlab.com. Last I saw, the blame was falling on CloudFlare, but there was no confirmation of that. It seemed region-specific.

I will note that one mitigation is to have a valid Kerberos TGT and make sure your browser is configured to use it with Fedora services (install the fedora-packager-kerberos RPM). You may still reauthenticate to Gitlab multiple times per day, but it will be happening in the background via GSSAPI and SAML, rather than interactively.

Metadata Update from @phsmoura:
- Issue priority set to: Waiting on Assignee (was: Needs Review)
- Issue tagged with: low-gain, low-trouble, ops

Unfortunate. Do you know if there's any issue on this we can track?

I guess there's not much we can do on our end...

Metadata Update from @kevin:
- Issue untagged with: low-gain, low-trouble, ops
- Issue priority set to: Needs Review (was: Waiting on Assignee)

@sgallagh Do you know of any docs that explain how to configure the browser in this way?

It would be nice if GitLab would let us choose how aggressive to make the SSO reauthentication… even once a week would be great. But if there is nothing we can do, there is nothing we can do. In that case, this ticket could be closed as Will Not/Can Not fix.

Metadata Update from @phsmoura:
- Issue close_status updated to: Will Not/Can Not fix
- Issue status updated to: Closed (was: Open)

As far as docs:

Just do a 'fkinit' (from fedora-packager package) and it will get a kerberos ticket for you. Your browser should automatically use that to authenticate with.

You do have to renew it every day, but if you are using gnome, you can add it to 'on line accounts' and it will automagically renew it for you for 1 week.

Some new evidence suggests that an interaction between CloudFlare and uBlock Origin (or other similar ad/tracker-blocking software) may be the culprit.
Metadata
None
None
None
None
Lowest
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.