Transition to new SSO domain and mandatory two-factor authentication enrollment

Infrastructure
,
1

Dear GNOME Foundation members, staff, and GNOME account holders,

Starting August 2024, we will be gradually transitioning our services from
direct LDAP integration and the old Keycloak instance at auth1.gnome.org to
a new Keycloak instance at sso.gnome.org.

Upon your next login through sso.gnome.org, you will be prompted to configure
two-factor authentication by scanning a QR code or manually entering the secret
in the app of your choice.

There are many 2FA apps available. We recommend the following:

  • Ente Auth, available for mobile and desktop devices,
  • 2FAS for Android and iOS devices,
  • Authenticator for Linux devices,
  • KeePassXC, which, while primarily a password manager, also offers 2FA support.

We are available to answer any questions over Discourse, Matrix or GitLab. We
will be updating this thread as the transition happens.

Thanks,
Bart

14 Likes
2

Is it possible to use more than one app?

3

You can scan the QR code using multiple apps, or enter the secret in multiple apps.

In general I would recommend making offline backups of TOTP secrets, like backups of GnuPG private keys.

4

Is it normal than logging into sso.gnome.org just results in just a loading spinner?

1 Like
5

If I understand the situation correctly, until @andyholmes’ GOA MR 269 gets design attention, gets merged into a stable GNOME release, and that release series has been around for two cycles ideally (ex: for people running the previous-but-still-supported version of Fedora instead of the latest bleeding edge version), this would mean breaking NextCloud integration for Foundation members and staffers…
Unless the plan is to make an exception for NextCloud authentication until that issue is resolved?

Personally, I pretty much depend on GNOME’s NextCloud server for Files integration (very convenient to upload testing samples for developers, right from Nautilus), contacts addressbooks, and some calendars, in Evolution and elsewhere. As far as I know, Evolution has no notion of “a NextCloud account” in its UI, and I’m not sure it provides a webflow authentication GUI, so we’re pretty much dependent on that GOA issue (@mcrha can correct me if I am wrong what I see as the current featureset in Evolution there)

6

I appreciate this is a workaround rather than a fix, but if you log in to Nextcloud via a browser, it might be possible to add an app password that allows the desktop integration to log in with just user/pass authentication? https://help.nextcloud.com/t/where-to-create-app-password/157454/2

DIsclaimer: I’ve not tried this on GNOME’s Nextcloud, but I have my own instance which uses OAuth2 and have made “plain” HTTPS login work for certain apps this way.

7

FWIW, Nextcloud’s Login Flow v2 is quite simple (needs curl and jq):

#!/bin/bash -e

# First argument is the server URI, defaulting to GNOME
server_uri="${1:-https://cloud.gnome.org}"
server_response=$(curl -s -X POST "${server_uri}/index.php/login/v2")

# Launch the login URL and start polling the endpoint
login_url=$(echo $server_response | jq -r '.login')
poll_endpoint=$(echo $server_response | jq -r '.poll.endpoint')
poll_token=$(echo $server_response | jq -r '.poll.token')

gio open $login_url && echo "Continue the login process in your browser."

while true; do
    poll_response=$(curl --http2 -s -X POST -d "token=$poll_token" -w "%{http_code}" $poll_endpoint)
    http_code=${poll_response: -3}
    body=${poll_response:0:-3}

    if [ "$http_code" -eq 200 ] && [ echo $body | jq -e '.server' > /dev/null 2>&1 ]; then
        echo "Authentication successful!"
        echo "Server:       $(echo $poll_response | jq -r '.server')"
        echo "Login Name:   $(echo $poll_response | jq -r '.loginName')"
        echo "App Password: $(echo $poll_response | jq -r '.appPassword')"
        exit
    elif [ "$http_code" -ne 404 ]; then
        echo "Unexpected HTTP status code: $http_code"
        exit 1
    fi

    # Check again in 5 seconds
    sleep 5
done

Of course, doing it safely in C takes a few more lines of code :wink:

8

My understanding is that this is exactly how it works. You generate an app token and use it as a password.

9

Due to some bizarre design choices, the root path redirects to the admin console. If you want to test the login flow now, either try here or log in to the test instance of BigBlueButton frontend here.

3 Likes
10

Hi,
the Evolution(-data-server) doesn’t have anything auth-related for the
Nextcloud servers, no. It relies on the standard CalDAV/CardDAV/WebDAV
API, just like with any other DAV servers.

There is currently no option for the authentication method for the sole
books/calendars/tasks/memos, but it’s more of a problem with the GUI,
than with the code. Consider for example the Google accounts configured
directly in the Evolution - they do OAuth2 for all the related sources.

The OAuth2 is specific with end points and client IDs and the like.
Does the GNOME SSO or the GNOME’s Nextcloud have any such thing? Or,
maybe, if I understood it correctly, is the Andy’s work with
https://cloud.gnome.org/index.php/login/v2
just this “something like OAuth2” end point, without a need for the
client ID and client secret and redirect URI and all that?

Bye,
Milan
11

Yes, exactly. Instead of a redirect URI, the initial response contains an endpoint/token to poll, which eventually returns a server/username/appPassword.

I’m not sure how GNOME’s authentication interfaces with our Nextcloud, but if there are any constraints on the “main” account password, the app passwords seem to bypass it.

12

hi, what does “gnome account holders” mean? is this for everyone with gitlab and damned lies accounts?

13

No, this is for people with LDAP accounts. You’re affected if you use Keycloak to sign into GitLab.

1 Like