Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1696434 - [RFE] Allow keystone to use SSSD for user authentication and lookup
Summary: [RFE] Allow keystone to use SSSD for user authentication and lookup
Keywords:
Status: NEW
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-keystone
Version: 16.0 (T)
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: ---
: ---
Assignee: John Dennis
QA Contact: nlevinki
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-04-04 20:17 UTC by Nathan Kinder
Modified: 2019-04-05 05:33 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:
Target Upstream Version:


Attachments (Terms of Use)

Description Nathan Kinder 2019-04-04 20:17:57 UTC
Currently, Keystone can use the following methods for identity (authentication and users/groups lookup):

  - local OSP SQL database
  - direct LDAP from keystone->LDAP (IdM, AD, etc.)
  - federation via OIDC/SAML

When Active Directory is used as the authoritative source for users/groups, there is the ability to use IdM with a trust to allow IdM to control policies for AD users (such as HBAC and sudo policies for administration of the overcloud nodes).

Unfortunately, there is not a good scalable way of using an IdM/AD trust with Keystone since Keystone can only use LDAP to interact with IdM.  For AD users to show up in LDAP search results, we have to use the "cn=compat" tree of IdM, which has been known to have performance issues in certain situations at scale, and also has had some difficult deadlock bugs in the past.

A more robust way of using a trust with Keystone would be to have Keystone somehow interact with SSSD directly on the controller node for authentication and identity lookup.  SSSD handles communication with IdM and AD when a trust is used, which doesn't rely on the "cn=compat" tree.  One possible way of doing this is to have Apache httpd modules perform the authentication and lookup.  There was a POC of this a few years back which used a combination of mod_auth_gssapi and mod_lookup_identity to authenticate and lookup user info, which is provided to Keystone as environment variables in the request.  To Keystone, this looks like Federation.  This allows the environment variables to be mapped to create a user object within Keystone.

We shoudl attempt to make SSSD usable for both password and Kerberos authentication with Keystone.


Note You need to log in before you can comment on or make changes to this bug.