51188 - [LDAP] Ability to put an LDAP username anywhere you can put an email address

Status: RESOLVED WONTFIX

(Bugzilla :: User Accounts, enhancement, P3)

Description

[Joe Robins]

When a Bugzilla site is using LDAP, one should be able to use an LDAP username 
rather than the user's email address to designate that user.  This needs to 
happen in several places:

1) In entering/modifying/querying bugs, when putting in an email address for any 
of the fields, there should be the option of putting in an LDAP username 
instead.

2) In editusers.cgi, when searching for users, an additional search option 
should be for LDAP username.

3) Possibly when creating groups, there should be an option to match against the 
LDAP DN rather than the email address?  This one I'm less sure of.

Hrm...  I have this nagging feeling I'm missing another place, but I'm not sure 
what.  In any case, I haven't done this part yet, so if people want to make 
comments/suggestions, please do.

Comment 1

[Dave Miller [:justdave]]

-> Bugzilla product

Comment 2

[Andreas Höfler]

Could this propably be easier to solve now with BZ 2.17.4 ?

Comment 3

[mag]

Attachment: Uses ldap username

This patch adds support for entering ldap uid where you have used to enter
email address.

Comment 4

[mag]

Attachment: LDAPmailattribute support

... and this changes the wired-in "mail" attribute to the configureable
LDAPmailattribute.

Sorry for being lousy.

Both patches are against 2.16.7

Comment 5

[Marc Schumann [:Wurblzap]]

Umm... We have LDAPmailattribute... Has this perhaps been fixed in the meantime?

Comment 6

[Teemu Mannermaa (:wicked)]

Comment on attachment 177194 [details] [diff] [review]
LDAPmailattribute support

Please combine this with the other patch..

Comment 7

[Teemu Mannermaa (:wicked)]

Comment on attachment 177192 [details] [diff] [review]
Uses ldap username

First of all, DBname_to_id has been moved to Bugzilla/User.pm in bug 283237. Also, there has been all sorts of LDAP connection changes in Bugzilla/Auth/Verify/LDAP.pm so they need to be taken into account. Maybe there should be a common sub somewhere that connects to the LDAP server?

Hmm, looks like this patch doesn't fully address all the changes presented in comment #0.

>+	if (!$LDAPconn) {
>+		print "Content-type: text/html\n\n";
>+		PutHeader("Unable to connect to LDAP server");
>+		print "I was unable to connect to the LDAP server";
>+		PutFooter();
>+		exit;
>+	}

Uhh, this needs to use Throw*Error to throw an error rather than hardcode HTML.

Comment 8

[Max Kanat-Alexander]

This should be much easier with the new Auth code, if anybody wants to take a stab at it.

It would just be a hack to User-matching, nowadays.

Comment 9

[Max Kanat-Alexander]

This doesn't seem to actually block bug 229049.

Comment 10

[Alexandra Kossovsky]

Attachment: patch to User.pm (in match function)

My patch adds Ldap-search functionality for user matching, when you type user name in CC list, assigner and so on.
This patch does not change editusers.cgi matching -- it has too complicated list of parameters, such as bugzilla group, so there is not straightforward way to fix it.
Also, it will be nice to get basic LDAP operations (ldap(), _bind_ldap_anonymously() and _bz_search_params()) to be available in more convenient place than Bugzilla/Auth/Verify/LDAP.pm.

Comment 11

[Tiago Mello [:timello]]

Attachment: v1

Comment 12

[Tiago Mello [:timello]]

Since we us(In reply to Tiago Mello [:timello] from comment #11)
> Created attachment 581387 [details] [diff] [review]
> v1

Since we use user auto-complete everywhere, that can be done with this patch.

Comment 13

[Emmanuel Seyman]

Comment on attachment 581387 [details] [diff] [review]
v1

I'm withdrawing the review request asked of me. I have no idea what this patch does and no idea how to test it.

FWIW, when I enter an LDAP username of the cc line and submit the change, I'm asked to confirm that I want said user to be put on cc so I'm unsure what problem you're trying to fix.

Comment 15

[Olav Vitters]

The patch makes it possible to suggest the LDAP userid, stored in extern_id. Mageia needs this functionality. LDAP userid matching doesn't work by default (on bugzilla.mageia.org).

Comment 16

[Benjamin Smedberg]

Comment on attachment 581387 [details] [diff] [review]
v1

Fixing empty review requests.

Comment 17

[Frédéric Buclin]

Comment on attachment 581387 [details] [diff] [review]
v1

>-        my $user_ids = $dbh->selectcol_arrayref($query, undef, ($wildstr, $wildstr));
>+        my @args = ($wildstr, $wildstr, $wildstr);
>+        my $user_ids = $dbh->selectcol_arrayref($query, undef, ($wildstr, $wildstr, $wildstr));

What is @args used for? Did you plan to use it in selectcol_arrayref()? Or is this just debug code which should be removed?


It's unclear to me if extern_id should be exposed to other users or not. I don't think we leak it anywhere, including using WebServices. Remember that LDAP is not the single authentication method, and I could imagine cases (including LDAP?) where extern_id should remain confidential, and only the Bugzilla login name should be exposed to other users. In your case, a user could use "brute force" to guess the extern_id value, and if he knows where the external authentication server is, he could then use this information to try to attack this server directly to gain access to the (LDAP) account.

@justdave: do we have any policy about what to do with the extern_id attribute? Is this a public attribute or a confidential one? I'm not a fan to see Bugzilla being used as a trojan horse to guess LDAP accounts.

Comment 18

[Dave Miller [:justdave]]

I don't know of an explicit policy, but the fact that it could be confidential for some login methods makes a lot of sense to me.  I think a better way to go about this would be to get that "login name != email address" bug fixed, and then allow the ldap authentication method to populate the correct login name when connecting to an account from ldap.

Comment 19

[Frédéric Buclin]

(In reply to Dave Miller [:justdave] ([e-mail]) from comment #18)
> better way to go about this would be to get that "login name != email
> address" bug fixed, and then allow the ldap authentication method to
> populate the correct login name when connecting to an account from ldap.

Yes, sounds good. So this means wontfix for this bug, due to potential confidential data leak.