Re: [gdm-list] Smartcard support in GDM?

[Mike Oliver <Mike Oliver Sun COM>]

gelgey vintela com wrote:
> [Apologies if this has been asked before, but the gdm-list
>   archives appear to be empty]

Where were you looking for the archives?  Perhaps you found a
bad URL that needs to be fixed.

> I've got some ideas, but I haven't yet decided on the appropriate course 
> of action. It really depends on what the PAM module is trying to 
> achieve, and whether GDM is merely reporting back that a token has been 
> inserted (which means only using PC/SC calls to check for token status 
> events), or whether GDM must inspect the token and fetch a username 
> (which means GDM must make PKCS#11 calls, and how a username is obtained 
> from a token, and what happens if there's more than one user represented 
> on a token).

GDM doesn't, and shouldn't, know anything about interacting with
smartcards.  Interacting with the card is entirely the
responsibility of the PAM module.  The PAM module can use GDM
(via GDM's PAM conversation callback function) if it needs to
interact with the user -- say, to obtain a PIN -- but interaction
with the card itself should be managed by the PAM module.  That's
true whether the interaction is at arm's length (say, via a
PKCS#11 framework) or more direct (say, via PC/SC).

Doing it this way has two enormous benefits.  The first is that
your implementation will work with any PAM-capable display
manager, not just GDM.  The second is that it will also work with
any PAM-capable screen locker.  OK, three benefits -- your
implementation will be decoupled from any particular revision of
any particular DM, which means that you won't have to wait for
distros to pick up your patches in order for this feature to
become widely available and you won't have to care about people
accidentally breaking your stuff when they tweak the DM.

The downside is that PAM has no good way of driving multiple
sources of authentication concurrently, so it's painful (at best)
to try to do something like "enter your username or insert your
smartcard".  Or "insert your smartcard or place your thumb on
the print reader or position your eye in front of the scanner
or exhale into the breath analyser".  The simplest way to
proceed is to ask the user to "enter your username, or insert
your card and then click 'restart' or 'OK'", and define the PAM
stack in such a way that it runs your PAM module on 'restart' or
'OK'.  This isn't very slick but it works.

Incidentally, the whole point of PAM is that the DM and/or
screenlocker shouldn't know that any of these technologies are
being used.  PAM takes on the job of discovering the username
and establishing authentication so that the DM is freed from
having to know any of the details of exactly how these things
are done.  If you're new to PAM then it will proably take some
time for this concept to sink in.

Before you start coding you might think about how this will work
with multiple authentication sources, not just a smartcard.
There's a sad history of non-interworkable kludges in this area
because everyone wants to make the login work with their
particular device and they end up doing it in a way that prevents
anyone else's device from being able to work too.  That's true
even *within* the smartcard realm, where you find that yes, you
can use a smartcard but access to it must be mediated by one
particular flavour of middleware, and perhaps you can only use
one particular kind of smartcard, and there's no way to go beyond
that.

Perhaps the time has come to extend PAM to be able to deal better
with these situations.

Mike.
--
mike oliver sun com