This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 828072 - [RFE] Allow authentication of users against LDAP Group objects
[RFE] Allow authentication of users against LDAP Group objects
Status: CLOSED UPSTREAM
Product: Pulp
Classification: Community
Component: user-experience (Show other bugs)
Master
Unspecified Unspecified
medium Severity unspecified
: ---
: ---
Assigned To: pulp-bugs
Preethi Thomas
: FutureFeature, Triaged
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-06-04 03:47 EDT by Nick Coghlan
Modified: 2015-02-28 18:39 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-02-18 19:48:40 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Pulp Redmine 172 None None None Never

  None (edit)
Description Nick Coghlan 2012-06-04 03:47:41 EDT
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.
Comment 1 Nick Coghlan 2012-06-14 02:34:23 EDT
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.
Comment 2 Nick Coghlan 2012-07-12 20:29:58 EDT
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 :)
Comment 3 Brian Bouterse 2015-02-18 19:48:40 EST
Moved to https://pulp.plan.io/issues/172

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