About this Document

Version	Date	Notes
Version 2 (This page)	15 February 2010	Changelog:
Version 1	10 February 2010	Initial cut; had concept of a new UI and an old UI.

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

Story 2: Fresh Install, Single-Domain User

Story 3: Fresh Install, Multi-Domain User

Story 4: Pre-configured Centrally-Managed Desktop

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
NIS settings

Mockups

Things To Note About These Mockups

Inkscape source for all mockups is available:
- Download Inkscape SVG
Access Keys have not been addressed in these mockups - but they'll need to be there
For the smart card components to show up (as in the current implementation) the following components need to be installed:
- coolkey
- ecid
- nss-tools
- ifd-egate
- pcsc-lite
For the MIS components to show up (as in the current implementation) the following components need to be installed:
- yp-tools
- ypbind

Identity & Authentication Tab

Main Dropdown Items

For the User Account Configuration > User Account Storage dropdown, the following fields should appear:
- LDAP
- NIS (if yp-tools && ypbind installed)
- Winbind
- Smartcard (if coolkey, ecid, nss-tools, ifd-egate, pcsc-lite installed)

If LDAP is selected under User Account Storage, only the following options should be available under Authentication Configuration > Authentication Method:
- LDAP
- Kerberos
If NIS is selected under User Account Storage, only the following options should be available under Authentication Configuration > Authentication Method:
- NIS
- Kerberos
If Winbind is selected under User Account Storage, only the following options should be available under Authentication Configuration > Authentication Method:
- Winbind
If Smartcard is selected under User Account Storage, only the following options should be available under Authentication Configuration > Authentication Method:
- Smartcard
- Kerberos

Paths Through the Tab

Path ID Number	Identity Technology	Authentication Technology	Backend technology	Mockup
1	LDAP	Kerberos	SSSD	View Mockup
2	LDAP	LDAP	SSSD	View Mockup
3	NIS	NIS	Legacy	View Mockup
4	NIS	Kerberos	Legacy	View Mockup
5	Winbind	Winbind	Legacy	View Mockup
6	Smartcard	Smartcard	Legacy	View Mockup
7	Smartcard	Kerberos	Legacy	View Mockup

Mockups By Path

Search

Design/SSSD

Contents