Single sign-on improvements in Fedora 24

How many times do you wish everything around you was a tiny bit smarter? A door opens automatically when you come in with bags of groceries. A light switches on when you step in. Entering a password twice in a row isn’t required to unlock your email after you logged in into your desktop.

Home automation has improved greatly in the last decade. Numerous sensors and smart switches are cheaper and more accessible every year. For example, offices and shopping malls in Finland have had automatically opening doors for years. Lights in my office switch off to conserve electricity when I’d get too deep into coding or a debugging session. Darkness is a result of me not moving much in my chair, as if I froze or need to be kicked out for a run.

Fitting single sign-on into the jigsaw

Yet, single sign-on and automated configuration for our tools remains a wish. In the enterprise environment, Linux systems often need to be configured by administrators in advance to allow users do just that: use all available resources. There are countless confusing articles, blog posts, and forum tragedies where a poor soul conquers the world of Kerberos, LDAP, networking file, or print services. Strangers give advice and laugh with an evil grin on attempts to follow the advice. This leaves the original person wishing it worked by itself.

Since 2009, Fedora started to package SSSD. Starting in 2011, FreeIPA also appeared in Fedora. These two projects try to untangle the complexity of corporate protocols. Combining LDAP, Kerberos, DNS, standalone certificate authorities, and a nice user interface, FreeIPA weaved together a set of tools to roll out corporate infrastructure completely based on free software in 10-15 minutes. SSSD, on other hand, made it possible to log in to FreeIPA from client computers where access rights are managed centrally and applied locally. Still, an administrator needs to enroll a client machine manually from the command line to allow its use and applications need to be configured manually too.

Adding machines from a GUI

Fedora 18 and 19 brought another improvement: it was now possible to enroll a client machine to Active Directory and FreeIPA from the graphical interface. Most of the details were discovered automatically. A name of the domain and an account were all you needed. Passwords were still needed to configure access to applications, but for some online resources, GNOME did gain the ability to configure access in a central place. This happens in GNOME Online Accounts. Email access, as well as remote access to file storage were now working after a single step of adding an online account.

The right to access these remote resources is usually granted for a week or two. Once the access has expired, you wouldd need to re-enter a password to obtain a new grant. For corporate resources, which often used Kerberos authentication, access would need a grant extension every twenty-four (or fewer) hours due to how Kerberos tickets are issued. While the Kerberos protocol allows renewing tickets in time and SSSD is able to renew them at login (or screensaver unlock), most account types in GNOME Online Accounts were not using this feature.

In a world of the cloud

In a cloud world, most remote applications tend to use HTTP or HTTPS protocols to communicate with your computer. This works just fine with a browser, which assumes a human is there, staring at the screen, answering questions, or clicking buttons. Some applications support more than password-based authentication. In particular, relaying the authentication process to another application became quite common. Web applications often ask for a ‘Social Network’ login. This delegates a password check to an existing remote source. In many cases, this is to Facebook, Google, or your own corporate portal.

Corporate portals often have support for Kerberos. It means your computer can talk to a corporate portal and automatically exchange authentication details if you have a valid Kerberos ticket. A portal then issues a session token that the original application can use to work with you.

libsoup helps make single sign-on possible

Since 2009, GNOME applications weren’t able to enjoy a first-class ride in such environments. Most, if not all of them, use libsoup for the network communication over HTTP or HTTPS protocols. In 2009, libsoup lost the ability to support “Negotiate” authentication. This includes Kerberos and NTLMSSP protocols. It took almost seven years to get a correct implementation back. This was a concerted effort of many people across multiple Linux distributions.

With the GNOME 3.20 release in late March 2016, libsoup added Negotiate authentication support again. If applications are using libsoup directly, they can request to authenticate with Kerberos or NTLMSSP credentials in a transparent way. However, many applications don’t use libsoup directly. Instead, they use a HTML engine called WebkitGTK+. WebkitGTK+ was changed as well to use libsoup’s Negotiate feature if a web site is accessed over HTTPS.

Altogether, this work enables a seemingly simple feature. If a Fedora 24 client is enrolled in FreeIPA or Active Directory, the user can directly go with Epiphany browser to any corporate website that supports Kerberos. By signing in to the system, the user can sign into it without entering any password again. A true single sign-on is now in place, without additional configuration beyond the original enrollment of the system.

Single sign-on with Yubikey

When working with Red Hat Desktop Team on these improvements, I recorded several videos to show how to use single sign-on in Fedora in real life. All of the features demonstrated in the videos are now possible with Fedora 24 Beta, though you can see through the artwork that it was show-cased with a patched Fedora 23 system. In February 2016 Fedora 24 was not yet available.

The first demo shows how to log into the Fedora Workstation as a user from a FreeIPA deployment. First with a password, then with two-factor authentication. A Kerberos ticket is obtained by SSSD after logging in directly over the Internet with the help of a Kerberos proxy. The same ticket is used to join (without a password) to an OpenConnect VPN. As we are part of our corporate environment, we can access the FreeIPA management console.

With the help of the FreeIPA console, we assign a Yubikey USB token to the user. When we try to unlock the screen again, GDM hints that both a first-factor (password) and a second-factor (an HOTP token generated by Yubikey hardware) key need to be entered. On successful login, SSSD renews the Kerberos ticket.

If you are interested how to configure Kerberos proxy and OpenConnect VPN to use Kerberos, check out this Red Hat article or an OpenConnect VPN recipe.

Single sign-on with Google Apps

Adding an Online Account from inside GNOME

The second demo shows how Epiphany transparently authenticates with Kerberos against FreeIPA web interface. Note that this user has an email address associated with the account. This email is managed by a Google Apps for Domain deployment. Therefore, we want to allow single sign-on to Google applications without giving Google any of our passwords.

To do so, we use the Ipsilon project. Ipsilon is an identity provider integrated with FreeIPA. Ipsilon implements SAMLv2 protocol and allows Google Apps for Domain to ask Ipsilon for authentication and the identity of the authenticated user. When we attempt to log into Google Apps, we get redirected to our Ipsilon server. The Ipsilon server offers an authentication choice using Kerberos, and the browser automatically signs us in. Ipsilon redirects us back to Google and we are able to access Google applications.

Fedora 24 includes both FreeIPA and Ipsilon to make it possible to configure your own Google Apps for Domain instance to authenticate against your own FreeIPA domain. Follow this article for more details.

ownCloud meets single sign-on

The same can be achieved in other cloud environments. The third video actually shows how this works with ownCloud. ownCloud is a self-hosted file sync and share server. It provides access to your data through a web interface, sync clients, or WebDAV while providing a platform to view, sync and share across devices easily — all under your control.

There, we configure Ipsilon to accept authentication requests coming from ownCloud. To do this, a

is created via ownCloud to send such requests. This is work in progress. For now, Adam Williamson’s module and a generic

Ipsilon client can be used to configure ownCloud.

Right now, using ownCloud and similar WebDAV-based sharing sites with Kerberos is not easy. Lots of work is continuing to improve GNOME Online Accounts to automatically acquire user credentials in case of unattended access to WebDAV resources protected with Ipsilon or similar Identity Providers.

Why does single sign-on matter to Fedora?

Why is all this work important to Fedora? After all, there are few enterprises that use Fedora in production. The answer would actually depend on how you see yourself. With FreeIPA and other solutions like Samba AD domain controller (coming soon to Fedora), it is now easy to deploy your own enterprise-grade environment at home, fully based on free software and independent of any external cloud identity provider. This makes Fedora a perfect place to shape corporate IT future and participate in bringing it to reality.

Fedora allows you to go further as the world today is more connected than before. People often follow where the current job creation rush is. This weaves its own distributed private networks of communication between families, relatives, and friends across borders. Today, these webs rely on social networks and clouds. Sometimes, they are not immune against government invasion. The editions of Fedora give the ability to truly stand on your own, and features like single sign-on make the use of your own communications easier for everyone. We are not getting younger with years, and neither our relatives and friends. User experience improvements make complex systems more accessible and allow the use of more secure technology to protect our environments.