F20 Self Contained Change: SSSD Smart Card Support

Jaroslav Reznik jreznik at redhat.com
Wed Jul 17 18:18:14 UTC 2013

= Proposed Self Contained Change: SSSD Smart Card Support =

Change owner(s): Nalin Dahyabhai <nalin at 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 
* 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 

Policies and guidelines:
* No new packaging guidelines. 

devel-announce mailing list
devel-announce at lists.fedoraproject.org

More information about the devel mailing list