Design/SSSD

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

1. User downloads a copy of Fedora from www.fedoraproject.org.
2. User installs Fedora using the default settings.
3. User boots machine and encounters firstboot.
4. One of the firstboot screens will ask the user whether or not they would like to use local logins or centrally-managed logins. (We'll avoid the use of the word 'network' since is more vague than 'centrally-managed' for Local-only users.)
5. The user will select that they would like a local login, fill out the needed info, and continue on with first boot.
6. The user will log into the desktop without issue.
7. Ideally, at this point, System > Administration > Authentication and System > Administration > Centrally-Managed Authentication will not be available. If they are, 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

1. User downloads a copy of Fedora from www.fedoraproject.org.
2. User installs Fedora using the default settings. They set up a local root account here.
3. User boots machine and encounters firstboot.
4. One of the firstboot screens will ask the user whether or not they would like to use local logins or centrally-managed logins. (We'll avoid the use of the word 'network' since is more vague than 'centrally-managed' for Local-only users.)
5. The user selects 'Centrally-managed'.
6. The user is asked to provide details about the type of system they need to connect to: if it's LDAP, Kerberos, or if it's hesiod, winbind, NIS, etc. If it's in the first group, the new SSSD UI is launched. If it's the latter group, the legacy UI that supports these technologies is launched.
7. 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.
8. The user may be anxious to set up a non-root local account. There will be a tooltip informing them they may do so later by logging in as root and using System > Administration > Users and Groups.
9. The user finishes firstboot, and attempts to log into their system.
10. Centrally-managed login works. Yay! All is good.
11. 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?)
12. User logs in as root, goes to System > Administration > Users and Groups and sets up a local non-root account if they really want to.

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 in system > administration > users and groups after login, 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. Here's the two choices:
  • Have one screen. Have users pick between a form to create a local account, and a form to launch a centrally-managed set up. One or the other, mutually exclusive. More convenient for the vast majority of users who just need to create a local account, as it's one single screen and all the fields they need to fill out are in-screen. Less convenient for the subset of centrally-managed users for whom a root-only local account is not sufficient.
  • Have two screens. First screen is for local account setup. Second screen asks if you want to set up centrally-managed auth, and if you do - it launches. This introduces a new screen for all users, which takes time to read and grok, makes firstboot longer, and takes more clicks to get through. It also makes the question local vs centrally-managed more stressful for users who don't know or care anything about centrally-managed auth (I would argue the vast majority of Fedora users.)

Story 3: Fresh Install, Multi-Domain User

1. User downloads a copy of Fedora from www.fedoraproject.org.
2. User installs Fedora using the default settings. They set up a local root account here.
3. User boots machine and encounters firstboot.
4. One of the firstboot screens will ask the user whether or not they would like to use local logins or centrally-managed logins. (We'll avoid the use of the word 'network' since is more vague than 'centrally-managed' for Local-only users.)
5. The user selects 'Centrally-managed'.
6. The user is asked to provide details about the type of system they need to connect to: if it's LDAP, Kerberos, or if it's hesiod, winbind, NIS, etc. If it's in the first group, the new SSSD UI is launched. If it's the latter group, the legacy UI that supports these technologies is launched.
7. If the two domains the user is interested in fall into different categories, let's assume the user makes the logical leap of picking the one they are more interested in.
8. Once the user sets up the domain, maybe there should be a tooltip to tell them configuring additional domains requires manually editing the config files.
9. 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.
10. The user may be anxious to set up a non-root local account. There will be a tooltip informing them they may do so later by logging in as root and using System > Administration > Users and Groups.
11. The user finishes firstboot, and attempts to log into their system. We assume it works.
12. The user logs in as root and manually configures the second domain in /etc.
13. IF the user goes to System > administration > authentication, they see both domains in the UI. Can they edit them?

Story 4: Pre-configured Centrally-Managed Desktop

1. User receives a company-issued desktop with Fedora or RHEL pre-installed on it.
2. 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.
   • Centrally-managed login works. Yay! All is good.
   • Centrally-managed login fails. Darn! What went wrong?
3. Let's assume it worked.
4. User clicks on System > Administration > Authentication (for legacy) or System > Administration > Centrally-Managed Authentication (SSSD ui). Prompted for root password.
   • If they have root, they can see the settings populated in the UI.
   • If they don't have root, they don't open the UI.

What login/authentication methods does SSSD support? What methods are supported by the legacy system?

SSSD

For looking up user accounts on the network, SSSD supports:

• LDAP servers (including POSIX-friendly Active Directory servers)
• IPA servers

NIS will be supported in the future.

For actual authentication, SSSD supports:

• Kerberos passwords
• LDAP passwords
• IPA passwords

Legacy System

The legacy system supports non-POSIX Active Directory servers via Winbind, Hesiod servers, NIS, smartcards, and fingerprint readers.

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.

• 

  User Info Tab

• 

  Authentication Tab

• 

  Options Tab

• 

  SSSD Tab

• 

  LDAP account settings

• 

  Hesiod account Settings

• 

  WinBind account settings

• 

  Kerberos auth settings

• 

  LDAP auth settings

• 

  WinBind auth settings

Mockups

Main Config UI

I did not like the editable listview widget suggested for editing key/value pairs here. That the fields are editable is not easily discoverable (most list widgets are not!) and it is also awkward to interact with them - very easy to lose entered data (ever tried to work with the IRC servers list in xchat-gnome? It uses this widget...) I'd rather that widgetry appropriate to each piece of technology appear based on the dropdown.

An example of how I would like it to work ideally is the evolution mail server UI, where if you pick IMAP vs POP3 vs some other options, the fields below the dropdown change to apply to the item in the dropdown.

Preferred Option

Source SVG for mockup below

Firstboot

Source SVG for two mockups below