1:18 p.m.
= Proposed Self Contained Change: SSSD Smart Card Support =
https://fedoraproject.org/wiki/Changes/SSSD_Smart_Card_Support
Change owner(s): Nalin Dahyabhai <nalin(a)fedoraproject.org>
During the F20 development cycle, SSSD intends to add support for
authenticating users using smart cards, much as it now supports doing so using
passwords, and to some extent, OTP tokens. This change tracks implementation
of that feature in SSSD, and if applicable or necessary, modifications to
applications and PAM configurations to properly make use of this new support.
== Detailed description ==
On a system that's using SSSD, a user should be able to log in at the console
(either text or graphical) using their user name and their smart card PIN. If
SSSD is configured to use a directory server, information from that server
should be used to verify that the card belongs to the right user. If SSSD is
configured to use Kerberos, SSSD should attempt to use the card to obtain a
Kerberos TGT for the user using PKINIT.
Text-mode login should handle this with minimum difficulty, since we'll just be
asking the user a different question at login-time, perhaps after asking the
user whether they'd like to use a password or the smart card. Graphical login
programs may want to provide a fancier UI than that.
== Scope ==
Because PAM-aware applications don't always support PAM conversations
sufficiently to be able to tell a user that we're asking for a smart card PIN
rather than their password, applications which do, and which want to support
smart cards, may need updates to their PAM configurations to tell pam_sss to
tell SSSD that they won't just ignore the text of a prompt and supply a
password when SSSD is asking for a PIN.
If we end up offering integration points that don't fit into the standard PAM
model (unsolicited notification of card insertion and removal may force this),
we may need to add a second API to SSSD to allow applications which want to
take advantage of that level of integration the ability to do so. Those
applications would need to be modified as well.
Proposal owners:
* SSSD will need to be able to handle authentication which requires multiple
round trips between an SSSD client and one of its backend processes.
* SSSD will need to be able to enumerate the set of smart cards that are
available on the system, preferably filter that list down to the ones which are
in readers attached to the same seat as the SSSD client process, and present
that list to either an SSSD client or to libkrb5 (which will then present a
list of things that it can use, which SSSD will massage and present to the
client).
* If a client supplies a PIN to use for logging in to a card, it will need to
log in to the card, and verify the certificate(s) on the card.
* Then, it should either use information from a directory server (the user's
userCertificate attribute, for a start, or by binding to the server as an SSL
client using the user's certificate and key, and then asking the server to tell
us which user we've authenticated to it as) to match the card to the user, or
attempt PKINIT using the card to get a Kerberos TGT for the user (this
implicitly gets the KDC to do the work of matching the card to the user).
Other developers:
* If authconfig controls the PAM configurations for the applications which
handle local login tightly enough, we'll want authconfig to add an option to
their invocations of pam_sss. If not, SSSD will need to infer things based on
service names.
* Where authconfig currently mixes pam_sss and pam_pkcs11, it will switch to
configuring just pam_sss.
* We'll need to coordinate with the GDM maintainers if they want to do
something fancier than that. (For example, noticing that a card has been
inserted, asking SSSD if anyone's logged in using that card before, and if so,
maybe adding a clickable target alongside the user name entry field to let the
user skip some typing. It would make for a nice tech demo, but privacy-
conscious users would want to disable it, so the less-fancy option, which
provides fewer clues to a would-be attacker, needs to always be available.)
Release engineering:
* No mass rebuild required.
* There will probably be new dependencies added to SSSD source and binary
packages.
Policies and guidelines:
* No new packaging guidelines.