From Fedora Project Wiki
No edit summary
 
(20 intermediate revisions by 4 users not shown)
Line 6: Line 6:


== Owner ==
== Owner ==
* Name: Rstrode
* Name: [[RayStrode | Ray Strode]]
* Email: rstrode at redhat dot com


== Current status ==
== Current status ==
* Targeted release: [[Releases/11|  Fedora 11]]  
* Targeted release: [[Releases/11|  Fedora 11]]  
* Last updated: Feb 20, 2009
* Last updated: April 17, 2009
* Percentage of completion: 65%
* Percentage of completion: 100%
 
gdm parts are done enough modulo bugs.  It still needs to be vetted upstream, though.
 
Fingerprint and smartcard plugins have been written.
 
authconfig has been changed to write out multiple pam stacks in addition to the traditional all-in-one stack.  It has a bug where it doesn't write out those stacks up upgrade yet though.
 
Still to do:
* bug fixing
* add configuration that decouples installation and enabling of gdm plugins (can be done post GA)
* add configuration that allows 2-factor authentication (can be done post GA)
* consider multiple stacks for gnome-screensaver, etc (may mean making gnome-screensaver defer to gdm)
* write documentation (can be done upstream/post GA)


== Detailed Description ==
== Detailed Description ==


Improve the GDM Login screen such that works better with multiple simultaneous authentication stacks. This will be accomplished by added a plugin framework to the GDM greeter that has APIs for plugins to instigate independent PAM conversations at the same time.  Each plugin will be responsible for shipping it's own PAM service file and UI for driving the PAM conversation associated with that service file.  Each plugin will also have the ability to affect the behavior of the login screen in response to external events (e.g., a smart card plugin might tell the login screen to start the PAM smart card authentication stack in response to a smart card getting inserted into the system).
Improve the GDM Login screen such that works better with multiple simultaneous authentication stacks and can adapt the UI to the currently used authentication method.
 
This will be accomplished by added a plugin framework to the GDM greeter that has APIs for plugins to instigate independent PAM conversations at the same time.  Each plugin will be responsible for shipping it's own PAM service file and UI for driving the PAM conversation associated with that service file.  Each plugin will also have the ability to affect the behavior of the login screen in response to external events (e.g., a smart card plugin might tell the login screen to start the PAM smart card authentication stack in response to a smart card getting inserted into the system).
 
Right now authconfig writes out a PAM service file system-auth that most other PAM services in the system "include". This service file does it's best to tie to together the configured authentication mechanisms for the system into one pam conversation. With the new GDM we have multiple conversations broken out, so system-auth isn't suitable anymore. Some of the stuff in system-auth we do need to carry over to the username/password conversation (for instance, ldap integration, kerberos integration, etc), and other bits we explicitly can't carry over (fingerprint, smartcard, etc). I have talked to Tomas Mraz to figure out the best way to reconcile this, and he agrees to having authconfig write out an additional stack in addition to system-auth.


== Benefit to Fedora ==
== Benefit to Fedora ==
Line 21: Line 39:
GDM currently only supports running one PAM conversation at a time.  This means if we want to support say Fingerprint OR username/password authentication, then we have to ship a PAM service file that has a specially crafted set of PAM stacks designed to run the fingerprint and username/password authentation modules in the right order.  When there are just two modules working together it's not a huge problem, but if you want 3 possible methods of logging into the system (say username/password, fingerprint, AND smartcard) then the logic neccessary to achieve that in one PAM service file becomes difficult.
GDM currently only supports running one PAM conversation at a time.  This means if we want to support say Fingerprint OR username/password authentication, then we have to ship a PAM service file that has a specially crafted set of PAM stacks designed to run the fingerprint and username/password authentation modules in the right order.  When there are just two modules working together it's not a huge problem, but if you want 3 possible methods of logging into the system (say username/password, fingerprint, AND smartcard) then the logic neccessary to achieve that in one PAM service file becomes difficult.


By running, e.g., the "smartcard" conversation indendently from the "password" conversation, we side step a lot of messy logic and module interaction issues.
By running, e.g., the "smartcard" conversation independently from the "password" conversation, we side step a lot of messy logic and module interaction issues.


Also, by having a plugin system specific to the GDM greeter, we can have UI that's less generic and more suited to the PAM conversations actually getting run.
Also, by having a plugin system specific to the GDM greeter, we can have UI that's less generic and more suited to the PAM conversations actually getting run.
Line 29: Line 47:
Requires implementing the above mentioned features, discussing how this change will affect other parts of the system (e.g. authconfig) with the relevant parties, and documenting the feature.
Requires implementing the above mentioned features, discussing how this change will affect other parts of the system (e.g. authconfig) with the relevant parties, and documenting the feature.


Right now authconfig writes out a PAM service file system-auth that most other PAM services in the system "include".  This service file does it's best to tie to together the configured authentication mechanisms for the system into one pam conversation.  With the new GDM we have multiple conversations broken out, so system-auth isn't suitable anymore.  Some of the stuff in system-auth we do need to carry over to the username/password conversation (for instance, ldap integration, kerberos integration, etc), and other bits we explicitly can't carry over (fingerprint, smartcard, etc).  I need to talk to Tomas Mraz to figure out the best way to reconcile this.  It may mean having authconfig write out an additional stack in addition to system-auth.
Affected packages:
* gdm
* authconfig
* new subpackages for the plugins


== Test Plan ==
== How To Test ==


{{Admon/note | This test plan is way too general.  We need to flesh it out more as the implementation details are figured out}}
{{Admon/note | This test plan is way too general.  We need to flesh it out more as the implementation details are figured out}}
# Configure the system to have multiple ways of authenticating
To test this feature in a useful way, you need to have multiple authentication methods available on your system, e.g. a fingerprint reader (common on modern laptops, see [[Features/Fingerprint]] for details), or a smartcard.
# Ensure that all ways work.
 
# Play around with authconfig and make sure things continue to work
# Configure the system to have multiple ways of authenticating. This can be done with authconfig (''System → Administration → Authentication'')
# Ensure that all ways work for logging in.
# Play around with authconfig and make sure things continue to work. gdm should pick up changes done in authconfig without a restart.
# Test that it is possible to cancel one authentication method, and use another one. E.g. swipe the wrong finger, then reconsider and type your password.
# Test that gdm initiates a smart card authentication upon inserting the smart card, and identifies the user from the smart card.


== User Experience ==
== User Experience ==
Line 52: Line 77:


http://git.gnome.org/cgit/preview/gdm/log/?h=multi-stack
http://git.gnome.org/cgit/preview/gdm/log/?h=multi-stack
While not a strict dependency, [[Features/Fingerprint]] and this feature will greatly benefit from each other.


== Contingency Plan ==
== Contingency Plan ==
* Shipping with the in-progress multi-stack patch but with only one stack enabled, or shipping without the patch and keeping the current behavior.
Shipping with the in-progress multi-stack patch but with only one stack enabled, or shipping without the patch and keeping the current behavior.


== Documentation ==
== Documentation ==
Line 60: Line 88:


== Release Notes ==
== Release Notes ==
{{Admon/note | There are no release notes written yet}}
The support for alternative authentication methods such as finger prints or smart cards in the gdm login screen has been improved. To enable alternative authentication methods, use authconfig (''System → Administration → Authentication'' in the menus).
 
----


[[Category:FeaturePageIncomplete]]
[[Category:FeatureAcceptedF11]]

Latest revision as of 13:57, 17 April 2009

Add Support for Multiple Simultaneous Authentication Conversations to Login Screen

Summary

Improve GDM's interaction with PAM so that it works with multiple simultaneous stacks at once.

Owner

Current status

  • Targeted release: Fedora 11
  • Last updated: April 17, 2009
  • Percentage of completion: 100%

gdm parts are done enough modulo bugs. It still needs to be vetted upstream, though.

Fingerprint and smartcard plugins have been written.

authconfig has been changed to write out multiple pam stacks in addition to the traditional all-in-one stack. It has a bug where it doesn't write out those stacks up upgrade yet though.

Still to do:

  • bug fixing
  • add configuration that decouples installation and enabling of gdm plugins (can be done post GA)
  • add configuration that allows 2-factor authentication (can be done post GA)
  • consider multiple stacks for gnome-screensaver, etc (may mean making gnome-screensaver defer to gdm)
  • write documentation (can be done upstream/post GA)

Detailed Description

Improve the GDM Login screen such that works better with multiple simultaneous authentication stacks and can adapt the UI to the currently used authentication method.

This will be accomplished by added a plugin framework to the GDM greeter that has APIs for plugins to instigate independent PAM conversations at the same time. Each plugin will be responsible for shipping it's own PAM service file and UI for driving the PAM conversation associated with that service file. Each plugin will also have the ability to affect the behavior of the login screen in response to external events (e.g., a smart card plugin might tell the login screen to start the PAM smart card authentication stack in response to a smart card getting inserted into the system).

Right now authconfig writes out a PAM service file system-auth that most other PAM services in the system "include". This service file does it's best to tie to together the configured authentication mechanisms for the system into one pam conversation. With the new GDM we have multiple conversations broken out, so system-auth isn't suitable anymore. Some of the stuff in system-auth we do need to carry over to the username/password conversation (for instance, ldap integration, kerberos integration, etc), and other bits we explicitly can't carry over (fingerprint, smartcard, etc). I have talked to Tomas Mraz to figure out the best way to reconcile this, and he agrees to having authconfig write out an additional stack in addition to system-auth.

Benefit to Fedora

GDM currently only supports running one PAM conversation at a time. This means if we want to support say Fingerprint OR username/password authentication, then we have to ship a PAM service file that has a specially crafted set of PAM stacks designed to run the fingerprint and username/password authentation modules in the right order. When there are just two modules working together it's not a huge problem, but if you want 3 possible methods of logging into the system (say username/password, fingerprint, AND smartcard) then the logic neccessary to achieve that in one PAM service file becomes difficult.

By running, e.g., the "smartcard" conversation independently from the "password" conversation, we side step a lot of messy logic and module interaction issues.

Also, by having a plugin system specific to the GDM greeter, we can have UI that's less generic and more suited to the PAM conversations actually getting run.

Scope

Requires implementing the above mentioned features, discussing how this change will affect other parts of the system (e.g. authconfig) with the relevant parties, and documenting the feature.

Affected packages:

  • gdm
  • authconfig
  • new subpackages for the plugins

How To Test

This test plan is way too general. We need to flesh it out more as the implementation details are figured out

To test this feature in a useful way, you need to have multiple authentication methods available on your system, e.g. a fingerprint reader (common on modern laptops, see Features/Fingerprint for details), or a smartcard.

  1. Configure the system to have multiple ways of authenticating. This can be done with authconfig (System → Administration → Authentication)
  2. Ensure that all ways work for logging in.
  3. Play around with authconfig and make sure things continue to work. gdm should pick up changes done in authconfig without a restart.
  4. Test that it is possible to cancel one authentication method, and use another one. E.g. swipe the wrong finger, then reconsider and type your password.
  5. Test that gdm initiates a smart card authentication upon inserting the smart card, and identifies the user from the smart card.

User Experience

  1. A lot of users of the update version of GDM won't notice any change at all.
  2. Users who wish to use their laptop's fingerprint readers or company mandated smartcards will notice a slicker experience.

Dependencies

The GDM changes this feature depends on are currently being pushed to the git repo here:

http://www.gnome.org/~halfline/gdm/

on the multi-stack branch. They're also in a temporary repo that could disappear at any moment here:

http://git.gnome.org/cgit/preview/gdm/log/?h=multi-stack


While not a strict dependency, Features/Fingerprint and this feature will greatly benefit from each other.

Contingency Plan

Shipping with the in-progress multi-stack patch but with only one stack enabled, or shipping without the patch and keeping the current behavior.

Documentation

There are no docs written yet

Release Notes

The support for alternative authentication methods such as finger prints or smart cards in the gdm login screen has been improved. To enable alternative authentication methods, use authconfig (System → Administration → Authentication in the menus).