Odd.

"All users in this group must set up two-factor authentication" is unset

We do have "Subgroups can set up their own two-factor authentication rules" so perhaps it's a subgroup setting things?

There's not been any change here recently that I am aware of. :(

Going right to https://gitlab.com/groups/fedora/-/saml/sso causes an authentication failed message for me. I had to click on the hyperlink while I was at https://gitlab.com/fedora to get it to log me in. I don't know if that would shine any light on what you're experiencing.

Going right to https://gitlab.com/groups/fedora/-/saml/sso causes an authentication failed message for me.

What failure do you get? I get a form with a "Sign in" button leading to https://gitlab.com/users/auth/group_saml?group_path=fedora&redirect_to=%2Ffedora to start the single sign-on authorization process.

I had to click on the hyperlink while I was at https://gitlab.com/fedora to get it to log me in.

What hyperlink? Do you mean "Sign in" https://gitlab.com/users/sign_in?redirect_to_referer=yes link on the https://gitlab.com/fedora page? That redirects me to a Cloudflare javascript captive portal. If I enable the Cloudflare script, I get https://gitlab.com/users/sign_in?redirect_to_referer=yes page which requires a user name and a password. That's not a single sing-on.

We do have "Subgroups can set up their own two-factor authentication rules" so perhaps it's a subgroup setting things?

What are the subgroups? Something like "legal" in https://gitlab.com/fedora/legal?

For completeness, source of the banner message is this one:

The group settings for <a href="/fedora">fedora</a> require you to enable Two-Factor Authentication for your account. You can <a rel="nofollow" data-method="delete" href="/groups/fedora/-/group_members/leave">leave fedora</a>.

I basically cannot do anything on gitlab.com after logging in with Fedora SSO. Almost all links resolves to the same 2FA setting page.

So I proceeded with setting up 2FA on Gitlab.com. Since then whenever login with a password or Fedora SSO, I'm asked for Gitlab.com's 2FA code.

So I proceeded with setting up 2FA on Gitlab.com. Since then whenever login with a password or Fedora SSO, I'm asked for Gitlab.com's 2FA code.

That's a GitLab thing and is by design. Whether I sign in with my Google SSO, GitHub SSO, Fedora SSO, or a local GitLab account (all tied together), I get the prompt for GitLab.com's SSO.

In another weird twist to how GitLab works, if I sign in with my Google or GitHub SSO, I don't get all of the access into the Fedora project space until I click the Fedora SSO login hyperlink. Once that goes through, I can immediately access content. If I use the Fedora SSO to log in, it also gives me direct access, but only if I clicked the link while on the Fedora group page in GitLab. If I try to just go direct to the Fedora GitLab SSO link from a bookmark or paste it into a new tab I get an authentication error after logging in.

In short, I'm pretty sure it's "working as intended" and has more to do with GitLab than the FAS SSO at this point.

Edit: GitLab also likely wouldn't prompt for enabling 2FA so long as a local GitLab password was not set. Some people do that when they see the "you need a password or an access token..." message at the top. Our local instance at my place of work is set up to be entirely SSO-integrated, and users do not have the option to locally register or opt in to password/2fa. They have to enable access tokens for things like IDE/editor integration, etc.

I understand that the 2FA request is made by GitLab and is tight to my account there.

I only wonder why "fedora" group cannot disable the requirement.

I have a separate account for accessing different group and it does not require 2FA. Neither when logging with a password or an SSO there.

I wouldn't mind if Fedora disabled password-based authentication to GitLab.com accounts, especially if it disabled the need for GitLab 2FA. However I fear that this is not how Fedora-Gitlab.com operates because the instructions for setting up the account are (or were when I use them) create an account and then attach Fedora SSO to it. And it wasn't possible to create an account without a password.

@ppisar Could you try again? I just enabled and then disabled the "Require 2FA" setting to see if there might have been a glitch in the database somewhere.

Something has changed: After logging in with SSO and Gitlab 2FA, I end up at Cloudflare captive portal and after enabling various javascript I got a Gitlab login form for a password. So I deleted all cookies and tried again, this time ended up in the normal Gitlab environment and logged it.

So I went to my account settings, disabled 2FA and end got the same enable-2FA form as I originally reported.

There is a message bar "Two-factor authentication has been disabled successfully!" followed with a bar: "The group settings for fedora require you to enable Two-Factor Authentication for your account. You can leave fedora. You need to do this before Sun, 01 Sep 2024 06:55:05 +0000. ".

So the only change is that the deadline has changed. But Gitlab still insists on enabling 2FA.

To be sure it's not some kind of a glitch in HTTP caching and blocking Javascript, I tried logging in from a fresh new Firefox profile and it behaves the same.

I have the same issue. Screenshot:

I have to add that I already have 2FA enabled in FAS. So I log into FAS with password + otp, and then I get forwarded to the GitLab page shown in the screenshot to enable a "second second factor". Somehow funny :)

I cannot change the GitLab page as it always redirected me to the one in the screenshot. I have not yet enabled the "2nd 2nd factor". Let's see what happens if the deadline shown in the screenshot is over. I'll report then.

I found the relevant Gitlab issue: https://gitlab.com/gitlab-org/gitlab/-/issues/427173

If a subgroup adds the 2FA requirement, it's applied to anyone in that group, including those who are part of it transitively from a parent group.

In our case, the https://gitlab.com/fedora/council group enabled mandatory 2FA and that resulted in it being required for everyone with access to it.

I have to add that I already have 2FA enabled in FAS. So I log into FAS with password + otp, and then I get forwarded to the GitLab page shown in the screenshot to enable a "second second factor". Somehow funny :)

That's entirely irrelevant; Gitlab can't know what the other end of the federated authentication requires, so it has to put its own requirements on the login.

That's entirely irrelevant; Gitlab can't know what the other end of the federated authentication requires

Yeah, I expected that ;) Anyway, it adds indication that it has to be expected that imposing this might be no acceptable condition for some. It might even encourage people to disable their 2FA in FAS, or avoid the GitLab and related contributions.

In our case, the https://gitlab.com/fedora/council group enabled mandatory 2FA and that resulted in it being required for everyone with access to it.

Does it make sense to suggest them to use the 2FA of our FAS instead? I don't see the sense to separate the FAS login with password from a 2nd factor in GitLab, except they have a very special use case (?). I guess it is at least worth to mention it.

The Fedora Council said we could disable that feature from their project, which I've done. I've scanned through most of the other sub-groups under /fedora and didn't see any others that had switched that on, so if someone affected could try again now, that would be great.

I just tried. Unfortunately, the issue remains in my case:

When I try to change to another GitLab page, it always redirects me immediately to this one.

Maybe the issue remains for those people who have tried to log in during the time the "enforced 2fa" was active (so those affected). Alternatively, it maybe takes some time until the whole GitLab infra is updated to no longer enforce the 2fa against FAS users.

I will try again tomorrow and see if it then works out. I'll let you know.

Thanks for taking care ;)

I will try again tomorrow and see if it then works out. I'll let you know.

I have now tested again. Unfortunately, the issue remains the same: My last screenshot of yesterday still applies:

The group settings for fedora require you to enable Two-Factor Authentication for your account. You can leave fedora.

I have already logged out and cleared cache/cookies, and then tried again, just in case something relevant is stored in cache/cookies that "keeps" the issue. But it doesn't change the behavior.

Sorry, got pulled onto higher-priority stuff.

There's probably another repo somewhere in the hierarchy that has this feature set and I need to write a script to recursively search them all. I just haven't had the time. I'll try to get to it when I can.

So, I noticed there's a '[x] allow subprojects to set their own 2fa rules' option that is checked.

Perhaps we should just uncheck that?

So, I noticed there's a '[x] allow subprojects to set their own 2fa rules' option that is checked.

Perhaps we should just uncheck that?

I just unchecked it; @py0xc3 (or anyone else without 2FA enabled): can you try again?

The issue remains, but the message has slightly changed and seems to contain some unintended condition:
(compare to my screenshot above, 2fa-page.png)

The second sentence in the error message is no longer "You can leave Fedora." (while "leave Fedora" contained a link; see previous screenshot of 2fa-page.png) but only "You can ." (with a "." at the end).

Also, the first sentence is now without "Fedora" (which also contained a link), which makes this sentence grammatically nonsense.

My expectation is that there is no longer a group that enforces this, and so the group is removed from the error message. But since the error was already invoked on my account, I assume the error will remain. I assume that's a gitlab bug: once this requirement was imposed on an account by its group (and it seems the imposition gets linked to the account if the user logs in during the requirement is set active), it will not be automatically removed, even if the requirements are no longer imposed by the group. Since this might affect all users who tried to login in the meantime (and other groups/projects who use gitlab), that might be reported to gitlab?