PAM for SQL Identity
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.
if (not user_ref
or not utils.check_
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_
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?
Blueprint information
- Status:
- Complete
- Approver:
- None
- Priority:
- Low
- Drafter:
- None
- Direction:
- Approved
- Assignee:
- Ken Thomas
- Definition:
- New
- Series goal:
- None
- Implementation:
-
Implemented
- Milestone target:
- None
- Started by
- Dolph Mathews
- Completed by
- Dolph Mathews
Related branches
Related bugs
Sprints
Whiteboard
I have implemented a local patch for LDAP authentication when using the SQL Identity backend. I am interested if people are looking to make this more generic interface which would allow a multitude of different authentication backends.
After toying with deploying the LDAP Identity backend we personally feel that fitting the data model going forward will always be challenging. Without a specific schema published by OpenStack I don't see a good way forward with the LDAP Identity backend.
That being said, LDAP, PAM and things like Oauth are very attractive for the authentication component for anyone deploying OpenStack at scale. Keeping passwords in a SQL database just means one more password for users. Keeping all the rest of the authorization components in SQL make a lot of sense.
How do people envision this to be implemented with respect to the current code layout (eg. something like Authentication backends for the SQL Identity Backend)?
This is now much easier to implement with the introduction of pluggable authentication in grizzly. This would simply be an alternative password plugin.
Gerrit topic: https:/
Addressed by: https:/
Tweak for easier, safer subclassing
