Cloned from launchpad blueprint https://blueprints.launchpad.net/keystone/+spec/sql-identiy-pam.

Description:

We have a need for using the sql.Identity to manage users, roles, and tenants, but we need to have a pluggable authorization module to authenticate our users rather than just checking the hashed passwords match what's in the database.

For example,  keystone.identity.backends.sql.Identity has the following snippet of code  in its authenticate method.

if (not user_ref
            or not utils.check_password(password, user_ref.get('password'))):

We need to change that check_password call to something specific to our needs.

I propose that we use a PAM that defaults to the existing check_password call, but allows people to provide their own PAM to do whatever authentication they need.

I also propose that keystone.conf contain an optional 'pam' field under [identify] where the module can be specified.

The work around that we're using for now is to subclass sql.Identity and reimpliement the authenticate method to do what we need.

Questions:

1. Does this sound of any use to y'all?

2. Would this be of use for the other identity backends? It looks like it could be used where ever utils.check_password is currently being called.

3. What should be done for backends that don't support it? Just ignore it?

I'll be happy to work on this if it's deemed useful.

Follow up suggestion... My concern about our current work around of subclassing sql.Identity is that I have to duplicate the entire authenticate method.  If there was a check_password method (like in ldap/core.py) then I could just overwrite that method and be assured that if things change in the base class, I won't need to reimplement my authenticate method. 

This change is much smaller in scope, but is it as useful as a general pam for the other identify classes?

Specification URL (additional information):

None