About this Project

What is SSSD?

SSSD (an acronym for 'System Security Services Daemon') is a Fedora Hosted free software project that aims to provide access to identity and authentication remote resource through a common framework that can provide caching and offline support to the system. It provides PAM and NSS modules, as well as D-BUS based interfaces. It provides also a better database to store local users as well as extended user data.

What is system-config-auth?

System-config-auth is a GUI utility used to set up both local and network authentication (user logins) to the system it runs on. The current legacy UI is very old. SSSD, a new system, is a much better technical solution to managing authentication than the legacy system. However, SSSD does not yet support as many authentication methods as the legacy system.

The legacy system is best classified as a set of cobbled-together technology pieces, while SSSD is more integrated.

What is the design problem?

We have a new developing technology, SSSD, to manage authentication and need to provide a UI design to help desktop users to configure authentication for their systems. There is a legacy UI in place to do this though - system-config-auth - and it is difficult-to-use. However, the old UI supports some functionality that has not been implemented in SSSD yet.

The challenges here are:

Design a new UI for setting SSSD configuration.

Enable users to still use the old UI for functionality not supported by SSSD/

Avoid revisiting the design of the old UI as we do not have developer resources and time to do this right now.

Guide users to the right UI for the job even though the criteria by which we determine the right UI for them are confusing and inconsistent.

Who is meant to use this UI?

First of all, these UIs are both accessible to users who have root-level access to the system in question. We restrict our target users to those users who administer their own system enough to have acquired root access. Users whose system is administered by someone else will have this setup already configured for them.

Secondly, while it is possible an administrator could use ssh -Y to connect to this configuration UI on remote servers with X & GTK+ installed, it is assumed that this tool will primarily be run on the system it is being used to configure. Therefore, we're assuming a desktop workstation with a monitor or a laptop, and that the user is sitting in front of the system.

Next, let's talk a little bit about system authentication. This application is targeted for users who use network-based / centrally-managed configuration. We assume the vast majority of Fedora and Linux desktop users use what is called 'local' authentication - this means the user account used to allow them to log into their system exists on the system and not in some centrally-managed database. These users will not get any use out of this UI. This is not to say these users would not interact with a remote account to say, get their corporate email. What this means, practically speaking, is that our assumption is that when most Fedora users turn on their system and get a GDM / KDM / XDM login screen in order to access a desktop environment on the system, the username and password they type on that login screen exist locally on that system, not in a centralized database.

Out of the subset of users that will use network-based, centrally-managed authentication systems, it is our assumption that 95% of these users will only need to authenticate to one domain (for example, a university network or a corporate network.) We assume that 5% or less of the set of users that will use centrally-managed authentication to log into their system will need to configure multiple domain authentication.

In summary, our design assumptions for the target of this UI are as follows:

Only users who use centrally-managed authentication - 95% of which will only need to worry about one domain.

Desktop users - either a desktop workstation or a laptop. We assume laptops will be more common.

Users will be physically present in front of the system they are configuring. They won't be configuring another system over the network.

Most Fedora users will not need to use this interface.

Only root-level users will have access to the interface. This means either power users / self-administered users will use it, or system administrators using the tool to generate configurations to deploy to other systems will use it.

Use-Cases

Case A: Single-Domain

This user uses a single centrally-managed account to log into their system, most likely their place of employment or maybe school (I assume most US schools don't do this though.) They may also have a local account for debugging / troubleshooting or for personal work on the same machine. This configuration will be supported by the UI.

Case B: Multi-Domain

This user may need to log into their machine using two or more accounts that are centrally-managed via two or more systems. For example, if a user is an employee for one corporation and a contractor for another, and has a login to each on the same computer. Extremely rare case. To address this case, the user will not be able to use the UI - instead, they will need to hand-configure this setup in the configuration file. If a user has multiple domains, they will almost never have more than 3 or 4, and 2 is the most common. Sometimes, the user might have domains configured that are not active. They may need a function to set them as active or inactive.

Case C: Local Only

This user only uses the built-in local authentication and account system. They do not need to access a centrally-managed database to log in. This case represents the vast majority of users.

Stories For How Users Will Encounter This UI

Story 1: Fresh Install, Local Only User

User downloads a copy of Fedora from www.fedoraproject.org.

User installs Fedora using the default settings.

User boots machine and encounters firstboot.

User encounters the 'create user' screen of firstboot. He or she is advised that if they need to set up centrally-managed logins, they'll need to click the 'use centrally-managed login' button (We'll avoid the use of the word 'network' since is more vague than 'centrally-managed' for local-only users.)

The user might click on the 'use centrally-managed login' button and get the system-config-auth dialog with two tabs in it, but hopefully will quickly realize it's not meant for them to use and close the dialog, continuing on with firstboot.

The user will log into the desktop without issue.

Ideally, at this point, System > Administration > Authentication will not be available. If it is, the user may open this up through exploration or by accident and encounter the UI there as well.

Story 2: Fresh Install, Single-Domain User

User downloads a copy of Fedora from www.fedoraproject.org.

User installs Fedora using the default settings. They set up a local root account here.

User boots machine and encounters firstboot.

User encounters the 'create user' screen of firstboot. He or she is advised that if they need to set up centrally-managed logins, they'll need to click the 'use centrally-managed login' button (We'll avoid the use of the word 'network' since is more vague than 'centrally-managed' for local-only users.)

User clicks the 'use centrally managed login' button and selects the combination of identity & auth settings they need to based on the technology on their network rather than sssd/legacy split. Depending on the choices the user makes, either sssd will be enabled or the legacy stack will be used.

What if the user doesn't know what technology the server uses? They'd be in a bind irregardless of the design here - they need this information to be able to set any of this up. We assume it's provided by their helpdesk.

The user may be anxious to set up a non-root local account. Should there be a tooltip informing them they may do so later by logging in as root and using System > Administration > Users and Groups??

User cannot log in as root to use to System > Administration > Users and Groups to set up a local non-root account - root logins are disabled.

The user finishes firstboot, and attempts to log into their system.

Centrally-managed login works. Yay! All is good.

Centrally-managed login fails. Darn! What went wrong?

Is there network access? (does GDM ask this troubleshooting question?)

Did the user set something up incorrectly? (does GDM suggest logging in as root and going to the auth ui to fix?)

Discussion

This user may be concerned at this point about setting up a local account. They have root already by this time, that's set up in the install program. We could tell the user to log in as root and set up a local account on the command-line, or we could let them create the local account right here (latter is more convenient.) However, that convenience may come at the expense of some convenience for the vast majority of Fedora users.

Story 3: Fresh Install, Multi-Domain User

User downloads a copy of Fedora from www.fedoraproject.org.

User installs Fedora using the default settings. They set up a local root account here.

User boots machine and encounters firstboot.

User encounters the 'create user' screen of firstboot. He or she is advised that if they need to set up centrally-managed logins, they'll need to click the 'use centrally-managed login' button (We'll avoid the use of the word 'network' since is more vague than 'centrally-managed' for local-only users.)

User clicks the 'use centrally managed login' button and selects the combination of identity & auth settings they need to based on the technology on their network rather than sssd/legacy split. Depending on the choices the user makes, either sssd will be enabled or the legacy stack will be used.

The user finishes firstboot, and attempts to log into their system.

Centrally-managed login works. Yay! All is good.

User manually edits configuration files to configure a second domain.

Story 4: Pre-configured Centrally-Managed Desktop

User receives a company-issued desktop with Fedora or RHEL pre-installed on it.

This laptop is pre-configured to log them into the corporate network. They turn it on and attempt to log into their system using credentials provided by their employer.

Legacy System

A Note About Offline Authentication

(If I understand correctly, this may be wrong, please correct --Duffy 01:30, 10 February 2010 (UTC)) Servers have policies that enforce how often a user may log in while offline without connecting to the authentication server, and can set when that cache expires. Client-side, you can also enable or disable offline login and how old the cache is allowed to get before the user must connect to the server. The server settings, of course, always override what you can set on the client. If the server says your cache will only last 3 days for offline, and you set it to expire after 99 years client-side - the server setting is going to trump the client setting.

These policies are meant mainly to require users to 'phone home' frequently enough to stay in compliance with account policies - for example, so the user will hit forced password changes. To the user, though, expiration means that until the user can connect to the appropriate network, they are effectively locked out of their account on their machine.

There is a tension here between the central system administrators' need to enforce their policies and the end users' need to be able to log into their system and get work done. Since the server policies trump the client-side policies anyway, I suggest to always set the client to enable offline login, with a cache that has an indefinite lifetime. In situations where this is unacceptable, clients may be deployed with a different default configuration. Also, the server would override the setting anyway.

Current UI

Here is a gallery of the current system-config-authentication UI from Fedora 12, taken 09 February 2010. Note that this UI is quite old, but the 'SSSD settings' tab was added recently as part of the first phase to integrate SSSD into Fedora 12.

Advanced Options Tab

Red Hat, Red Hat Enterprise Linux, the Shadowman logo, and JBoss are trademarks or registered trademarks of
Red Hat, Inc. or its subsidiaries in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the U.S. and other countries.
The Fedora Project is maintained and driven by the community and sponsored by Red Hat. This is a community
maintained site. Red Hat is not responsible for content.