This article continues the discussion about FreeIPA authentication improvements and how they could benefit Fedora Infrastructure.

FreeIPA 4.9.10 has added support for relaying authentication to OAuth2 identity providers (IdPs). Users would get their access to FreeIPA resources mediated by an external OAuth2 identity provider which supports OAuth2 device authorization grant flow (RFC 8628). This is not too dissimilar from how smart TVs connect to Youtube and other media services on your behalf. A user would be able to grant access to a scoped information to a FreeIPA OAuth2 client registered with such IdP. In order to authorize the access, the user might need to login to the IdP first and this is performed with the help of a browser running elsewhere. Most common browsers do have support for Webauthn/FIDO2 tokens, thus it is possible to build a system where a login to FreeIPA-enrolled system is authenticated by the FIDO2 token exclusively.

Based on the result of the external IdP authorization grant, FreeIPA would then issue a Kerberos ticket to the user. The ticket can then be used for single sign-on across all FreeIPA services.

The functionality to authenticate against an external IdP is already available in Fedora 36 versions of FreeIPA and SSSD. It is also available in RHEL 8.7 and 9.1 beta versions published in late September 2022.

Relying on an external identity provider to authenticate your FreeIPA users would also mean rethinking the relationship between the IdP and the FreeIPA deployment. Typically, when people integrated FreeIPA with OAuth2 or SAML identity providers, an assumption was made that user authentication is handled by the FreeIPA servers and identity provider issues a token for a web application. Turning this situation around means FreeIPA only becomes a user data store – maybe even not the data store for the IdP itself. IdP would only need to know about the user identity from its own point of view while FreeIPA would have a POSIX identity of the same user, consumed by other applications. Whether it is visible through the IdP grants or via POSIX interfaces is more of an application implementation detail. Decoupling these details leads to a bit of duplication, of course, but allows for better flexibility. A user might come from a federated source and have their authentication handled by a different identity provider – their public service provider like Google, Github, Gitlab, or Microsoft Azure. Or Facebook and any other social media.

All this, however, would mean a change to the way Fedora Accounts system and Fedora IdP, Ipsilon, interact with each other. Right now Ipsilon sources accounts information from the FreeIPA instance directly and delegates authentication to it as well (though PAM service provided by SSSD). Fedora Accounts system, in its turn, manages passwords and tokens in the FreeIPA instance. Since FreeIPA does not have support for Webauthn/FIDO2 web-based authentication yet, Ipsilon would need to manage that itself. So some user accounts would need to source their authentication details from FreeIPA and some would need to use Ipsilon’s internal source. That is a bit complicated as Ipsilon has no way to combine data sources.

Ipsilon does not have any support for both OAuth2 device authorization grant flow and Webauthn/FIDO2 tokens. Even if the FreeIPA instance used by both Fedora project and CentOS project would be updated to provide external IdP authentication, the Ipsilon instance would not be able to utilize this new feature.

Another alternative would be to use Keycloak (free software project upon which Red Hat Single Sign-On product is built). Keycloak 21 is adding multiple user stores support and the FreeIPA team works on a new provider to utilize it. This new Keycloak user store plugin supports SCIM v2 API and also needs a new FreeIPA application that abstracts out access to FreeIPA resources as a SCIM v2 API. In the end, it is the same SSSD as a backend as in case of the Ipsilon IdP but with the ability to split the data store across multiple sources. Keycloak already has support for both OAuth2 device authorization grant flow and the Webauthn/FIDO2 tokens. How this all works together is shown in our Nest with Fedora 2022 talk. Talk slides can be found here but the video includes a live demo session.

On mobile devices front, both Google and Apple are gearing towards introduction of software tokens for Webauthn/FIDO2, often called ‘passkeys’ in the user-oriented marketing materials. These passkeys effectively shared across devices where a user is logged in and uses a shared password wallet. The Google Security team goes at length explaining why this is secure, although some researchers aren’t convinced (this is more about Apple implementation, though).

Consuming software tokens stored in a mobile device from a computer for authentication would need additional support from the identity providers. Neither Ipsilon nor Keycloak implement that. For native Android applications Google just announced they’ll provide an API in what remains of 2022.

Finally, going outside of Fedora Project’s infrastructure, supporting Webauthn/FIDO2 to login to Linux servers and desktops in a centrally managed way is still not there.

Both FreeIPA and SSSD teams are working on a more direct integration with FIDO2 tokens. Instead of relying on an OAuth2 identity provider to handle Webauthn/FIDO2 operations in the browser, SSSD is integrating with libfido2 library to make FIDO2 token’s use on the machine locally. This would replace the pam_u2f module and would allow FreeIPA to provide centralized management of the FIDO2-based passkeys. On top of that, FreeIPA will provide Kerberos integration: login with the FIDO2 token would be turned into a Kerberos ticket and single sign-on operations would be ensured across multiple services, like it is done today for traditional Kerberos pre-authentication methods. A benefit is that passwords can be completely removed for the users with direct FIDO2 token enrollment.

FreeIPA-enrolled clients (Fedora 36+, RHEL 8.7/9.1 betas) already can login via external IdP as outlined above but only for the SSH or a direct console login. Login over graphical desktop is not working well: a message telling to visit an IdP page and authorize the device access does not fit into a gdm login entry which is used to show the message coming from the PAM stack. GDM is also not able to go to that URL directly as there is still no support for opening a browser instance pre-login in GNOME or any other desktop manager. We are looking at implementing this with GNOME developers similar to how a smartcard selection was added in 2017. Hopefully, this will come to one of the next Fedora versions …

Notwithstanding open issues, we are pretty much close to enabling FreeIPA-enrolled Linux systems to go passwordless. It is not yet a year of passwordless Linux like not a year of Linux on the desktop but making it reality is not that far away. Perhaps I am too optimistic, though – like we were all before with Linux on the desktop.