Description of problem: LDAP group queries are currently only possible if the LDAP server provides "memberOf" attributes (or an equivalent) on User objects. RFC2307 compliant servers that only store group membership on the Group objects cannot be queried. The "base" attribute assumes "ou=Users" and the filter setting queries the attributes of the returned user objects. There's currently no way I can see to turn this around and query ou=Group to see if the user id is present in the group member list.
I created BZ#831937 to request an alternative approach that I believe would be superior: allowing Pulp to be configured to delegate the REST API authentication and authorisation checks to the web server.
After creating the patch attached to BZ#831937, I realised the two issues (Apache level authentication & authorisation and better LDAP integration) are actually fairly orthogonal. I also realised I don't need the enhanced LDAP authorisation right now, but I suspect it may become more important in the future to map different LDAP filters to different roles rather than being limited to a single filter->role mapping as is the case now. I did do some design work before deciding I didn't actually need the feature yet, and this RFE seems like a better place to capture that than the mailing list (copied from https://www.redhat.com/archives/pulp-list/2012-June/msg00052.html): =================== The current LDAP authorization support is rather limited - consisting solely of the "filter" option in the [ldap] config settings, along with the "default-role" setting in that section. This is limited in three ways: - it doesn't handle web server level preauthentication in the absence of LDAP - it only allows LDAP filters against users (not LDAP groups), which is a problem if the LDAP server doesn't provide "memberOf" attributes on user records - it doesn't allow for per-role LDAP filters To deal with the first limitation, I plan to add a "default-role" option to the [security] section of the config file that is automatically granted to *all* users when first created. LDAP authenticated users would then get both the security default role *and* the ldap default role (if any) when they first logged in. Both default-role entries become optional. For the latter two limitations, I plan to implement a couple of new configuration sections: "ldap-user-roles" and "ldap-group-roles" The format of these new sections are currently going to be: [ldap-user-roles] role-name: <LDAP user filter> [ldap-group-roles] role-name: <LDAP group filter> The role names are only checked against the database when a user logs in via web server preauthentication. If the role name doesn't exist, that results in a warning in the Pulp log file but is otherwise ignored. When a user is created implicitly (either via LDAP authentication or web server preauthentication) the following automatic role assignment checks will be performed: If security.default-role is defined: the new user is granted that role If LDAP is configured and the username matches a uid in LDAP (taking ldap.filter into account): If ldap.default-role is defined: the new user is granted that role For each role:role-filter pair in ldap-user-roles: If (&(uid=<username>)<role-filter>) returns a non-empty list: the new user is granted that role For each role:role-filter pair in ldap-group-roles: If (&(uid=<username>)<role-filter>) returns a non-empty list: the new user is granted that role If, after all this, the user has no roles assigned: They are not authorized for any access, and the login attempt fails Otherwise, the user is created and more specific role-based authorization checks proceed as usual =================== Hope this helps for the great 2.0 auth refactor :)
Moved to https://pulp.plan.io/issues/172