From Fedora Project Wiki

< Changes
Revision as of 11:48, 25 July 2013 by Jreznik (talk | contribs) (Change accepted en block on Jul 24 FESCo meeting (#1140))



SSSD Smart Card Support

Summary

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.

Owner

Current status

  • Targeted release: 20
  • Last updated: 2013-07-15
  • Tracker bug: <will be assigned by the Wrangler>

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.

Benefit to Fedora

While it's long been technically possible to integrate smart card support with system login, mixing that with networked sources of identity information and networked authentication schemes (specifically, LDAP and Kerberos) has been complicated and difficult to troubleshoot due to the need to configure multiple PAM modules and several configuration files in order to get things to work.

Hopefully, teaching SSSD to handle logging in with cards, while taking advantage of the information sources that it's already configured to know about, will simplify things for SSSD users.

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.

Upgrade/compatibility impact

Existing functionality shouldn't be lost when upgrading.

How To Test

  1. You will need an enrolled smart card and a supported reader. Specifically, if you have opensc installed, you should already be able to check that the token is visible by running pkcs11-tool -T --module=$MODULE with the appropriate PKCS#11 module.
  2. You will need to install SSSD and point it to either:
    • an LDAP server which contains an entry identifying the user, and which contains the user's card's signing certificate as its userCertificate attribute, or
    • a Kerberos KDC which has been configured to provide PKINIT services such that you're already able to use kinit -X X509_user_identity=$MODULE to obtain a TGT
  3. Profit Attempt to log in, once without the card inserted into the card reader, once with.
  4. When the card is in the reader, you should be able to log in without supplying your password. If you're using Kerberos, you should have a TGT during your login session.

User Experience

  • When logging in at the console in text mode, the user may be asked whether they would like to use a password or one or another locally-plugged-in smart card.
  • When logging in using a GUI, the user may be asked whether they would like to use a password or one or another locally-plugged-in smart card, or the option may be presented when a card is inserted.

Dependencies

  • authconfig is going to need to know what's going on at all times

Contingency Plan

  • If not ready for F20, we slip to F21.
  • Because any special logic that has been added to applications would still not be triggered for password-based login cases, they should be unaffected so long as they can handle running on a system with the F19 build of SSSD, which currently (sssd-1.10.0) has none of the functionality we're discussing here.
  • The lone exception is authconfig, since it will need to revert to writing configurations they way it did in F19.
  • Contingency mechanism:
    • Signal to maintainers of involved packages that we're not landing this, no later than one week before beta freeze.
    • The authconfig maintainer will probably grumble, but everyone else will just shrug and go back to whatever else they were doing.
  • Contingency deadline:

This is not intended to be a release-blocking change.

  • Blocks release?

This is not intended to be a release-blocking change.

Documentation

So far, this is it. It's early days.

Release Notes

Retrieved from "https://fedoraproject.org/w/index.php?title=Changes/SSSD_Smart_Card_Support&oldid=346572"