Re: [gdm-list] [RFE] A modular gdm greeter

[Simo Sorce <ssorce redhat com>]

On Wed, 2007-10-03 at 18:25 -0400, William Jon McCann wrote:
> Hi Simo,

> Very much in agreement.
> "Username or insert card or scan iris or swipe finger:"

Exactly.

> > Face/Avatar browser:
> > A pluggable system would let you choose whether to actually show a list
> > of users, how to filter it and how to populate it. There are many
> > methods to present such list and it is easier to swap in a different
> > plugin then trying to provide all possible ways by means of
> > configuration options.
> 
> Perhaps.  It isn't a panacea.  It can make it more difficult to create
> a well integrated experience - or perform animation etc.  Anyway...

Uhmm why? I was thinking it would make it simpler actually.


> Completely agree.  This is exactly what I hope to do with the user
> chooser.  I think we should always display this chooser.  The other
> question is when should we also display a username field?  In general,
> whenever we have any non-local directory - but how do we detect that
> other than by timeout/number of users?

Timeout/Num of users seem a really poor way to deal with this.
This is a deficiency in the NSS interface as it built around assumptions
that are wrong in today computing environment. I am personally against
using enumeration, and I'd like to be able to tell my GDM to only
remember successful logins and show faces for those as a shortcut.
Eventually a plugin could implement a way to browse for users in the
database of choice if the admins feels that browsing as anonymous is not
considered a security problem (I wouldn't allow that probably).

But the beauty of a pluggable interface is that it make it easier to
make your own choices :-)

> But yeah, the
> domain chooser is a good example of something that most people won't
> want to see.  How do we detect that it should be displayed?

Well I think we have no way here but to use some smart detection of the
available NSS modules or to configure it, again the beuty of having
plugins is that you can choose how to do it. I believe enabling
experimentation in this field can lead to better understanding of the
requirements in the long term.

> >
> > Smartcard/Fingerprint readder:
> >
> > These kind of devices have a different way to interact with users then a
> > normal username/password prompt. Ideally a user should be allowed to
> > just swipe the finger/insert a smartcard without being requested neither
> > a username, nor a password, but still you want to make them interact
> > with pam so that all access limits and other useful pam modules are
> > correctly invoked.
> > Again a plugin could change the UI to show a smart card or a finger
> > print reader and once the smart card is inserted or the finger swiped
> > they could build a username to be passed to pam to start the
> > conversation and later pass in whatever token the corresponding pam
> > module expects to finalize authentication.
> 
> This is an interesting case for a number of reasons.  As you say, it
> still needs to go through PAM - and in some cases the authentication
> is two factor.  But PAM isn't sufficient.  We need something to
> interrupt and restart the PAM stack.  And we certainly shouldn't be
> doing anything if this particular seat doesn't have the necessary
> hardware.

Yes, I don;t have all the answers of course, but I am trying to find a
way to finding answers possible by building a mechanism that let's users
experiment easily.

> 
> > Conclusions:
> >
> > Trying to address all these scenarios with a generic module or trying to
> > do it using only PAM conversations would probably result in a poor UI
> > experience like it is now. Also, as PAM is serialized, combination of
> > the above would be really nasty as a user may end up being require to
> > fail an authentication method on purpose just to be asked for the right
> > stuff.
> >
> > As an example a desktop set-up to use smartcards for some logins but
> > still allowing windows domain logons for legacy windows domains. In this
> > situation a plugin system could allow the GDM greeter to show both a
> > smartcard sign and a domain list chooser, it can be done by a tabbed
> > greeter or something else (with persistence, ie the next time the
> > default tab is set to be the last used), the modular system should allow
> > you to handle that and also nest multiple plugins when necessary. Once a
> > plugin starts getting input it becomes the dominant one and try to
> > perform an authentication, all others become disabled until either login
> > succeeds or fails.
> 
> Can you give an example of how this might work?  The other examples
> you give are mostly about setting up the initial conditions rather
> than handling PAM conversations.

Just as a very hacky example, I am not saying this is the right way to
do it:
Suppose you have an environment were smartcards are common but you also
have to deal with traditional logins. What could be done is to have a
tabbed GDM were a user can switch between the calssic username/password
request tab and the smartcard tab.
Now the smartcard plugin may handle the PAM conversation so that only
warnings are displayed and other input fields are returned empty until
you get pack the request for a PIN or the conversation fails. This would
make it possible to handle a pam stack where pam_unix is before
pam_smartcard without having 2 different stacks. (I am starting thinking
that having multiple stacks seem a more and more appealing idea).

This means the plugin would be strictly tied to the specific PAM
configuration but would make things smoother for users. This is probably
a poor example, it is just the first that came to mind. But being able
to handle stacks with multiple pam modules for different auth mechanisms
is what I'd like to be able to address.

It is much easier for the case where you have both pam_winbindd and
pam_unix as in that case one module can use the first module password
and the same interface can be used without tricks to discard messages,
or catch them to display graphics instead of text.

> Certainly.  But how do you propose to marshal the PAM messages to the
> respective plugins?  Just sending them to one plugin regardless of
> what PAM module sent them doesn't seem right either...

This is a hard point. I guess experimentation is necessary to fully
understand all implications.

> But anyway, these are good ideas.  Thanks for starting the discussion!

Thanks you, I hope we can get to something reasonable in a reasonable
time :-)

Simo.