About this Project
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. 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. 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.
We assume the vast majority of Fedora users will not ever need to use this new UI, as it is meant to pertain to network-based, centrally-managed authentication systems only. However, out of the subset of users that will use 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.
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 login/authentication methods does SSSD support? What methods are supported by the legacy system?
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
The legacy system supports non-POSIX Active Directory servers via Winbind, Hesiod servers, NIS, smartcards, and fingerprint readers.
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.