Bug 1041902

Summary: [RFE][keystone]: PAM for SQL Identity
Product: Red Hat OpenStack Reporter: RHOS Integration <rhos-integ>
Component: RFEsAssignee: RHOS Maint <rhos-maint>
Status: CLOSED UPSTREAM QA Contact:
Severity: low Docs Contact:
Priority: unspecified    
Version: unspecifiedCC: markmc, yeylon
Target Milestone: ---Keywords: FutureFeature
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
URL: https://blueprints.launchpad.net/keystone/+spec/sql-identiy-pam
Whiteboard: upstream_milestone_none upstream_status_implemented upstream_definition_new
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-03-19 16:59:50 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description RHOS Integration 2013-12-12 19:58:57 UTC
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