UID configuration is ignored

[mhutter]

Given the following parameters:

{:title=>"My LDAP",
 :host=>"1.2.3.4",
 :port=>636,
 :method=>"ssl",
 :base=>"ou=snip,dc=snip,dc=example,dc=com",
 :uid=>"sAMAccountName",
 :bind_dn=>"snip",
 :password=>"snip"}

I expect my UID to be equal to the sAMAccountName provided by my LDAP server. However, the UID is always the DN.

[rkesters]

Hi, I submitted a pull request #38 for this back in 2013, I'm sure it's out of date by now. If the maintainers decide to give the request consideration I'll update the request so that it merges correctly.

[openface]

bump

Would be great to have this fixed. Seems irregardless of the uid setting, the dn from the ldap entry is always assigned to the uid in AuthHash.

[pboling]

Why DN for auth.uid?:

Rationale: DN is canonical and globally unique across directories; attributes like uid/sAMAccountName may be absent or inconsistent between servers.

References LDAP RFCs:

• RFC 4511 defines LDAPv3 protocol behavior and the centrality of the DN for entries.
• RFC 4514 defines the string representation for Distinguished Names, supporting DN as a stable identifier.
• RFC 4519 catalogs common attribute names (including uid), but attributes are schema- and directory-dependent; they aren’t guaranteed to be globally unique or present. This variability is why using the DN for auth.uid is a safe, cross-directory default.

Where to find the "username"-style value?

• auth.info.nickname maps from the first present of: uid, userid, or sAMAccountName.
• You can also read the raw attribute from auth.extra.raw_info (a Net::LDAP::Entry)

Example

get "/auth/ldap/callback" do
  auth = request.env["omniauth.auth"]
  dn = auth.uid                                # => "cn=alice,ou=users,dc=example,dc=com"
  username = auth.info.nickname                # => "alice" (from uid/sAMAccountName)
  # Or, directly from raw_info (case-insensitive keys):
  sam = auth.extra.raw_info[:samaccountname]&.first
  # ...
end

I'm updating the documentation to this effect, and I've added a spec that showcases this behavior as expected:
#101