Ryan et al.:
Congrats on Extension:LDAP_Authentication, You're doing some
great work
here.
Thanks.
Our systems are:
- FreeBSD 6.x / amd64
- OpenLDAP 2.3.4x
- Apache 2.3
- PHP 5.2.5
- WM 1.11.0 from Ports
- TLS works
- Proxy User works
- I've managed to make things work with our non-standard LDAP tree
So far the only problems that I've encountered
- "Proxy Agent" is ambiguous and even misleading. If you look at
something like PADL PAM_LDAP or NSS_LDAP, they simply refer to these
as "bindpw" and "bindcn" -- or even a better name is
"MetaUser" since
LDAP as a whole is ambiguous as to what constitutes a user
or identity
(a DN).
Yeah, this is slightly ambiguous. In some cases it does actually act
like a proxy user though. I've thought about changing it in the past,
but unfortunately, changing options causes serious support/documentation
issues. I could keep backwards compatability, and assign the new
variable to the old one in the code, but then the code will start to get
messy (and messy usually equals buggy).
- WRT groups, It isn't entirely clear which
settings control
which group
a UID=/CN= must be a member of (PADL calls this
$pam_groupdn) v.s. how
meta-group member _WITHIN_ media-wiki is determined (PADL call it
$nss_base_group)
Essentially, you use the group settings to let the plugin know how your
groups are defined using:
http://www.mediawiki.org/wiki/Ldap#Group_options
Once the wiki knows how to find groups, you can tell the wiki to
syncronize groups with mediawiki's groups using:
$wgLDAPUseLDAPGroups
If you want to restrict login access to specific groups, you define
those groups in:
$wgLDAPRequiredGroups (this attribute serves the same purpose as
pam_groupdn)
If you want the plugin to search inside of specific ou instead of using
the basedn, you define:
$wgLDAPGroupBaseDNs (this attribute serves the same purpose as
nss_base_group)
I *should* have modeled my plugin a little more off of PADL, but overall
the way things work in the plugin arent too far off. PADL has a set of
defaults that is geared to a Linux/Unix style LDAP setup; my plugin
doesn't, which is why you need to set more options.
- $wgLDAPProxyAgentPassword isn't accepting a
proper SHA1+Base64'd
password -- I've resorted to storing it in cleartext. Will debug
later.
I may have been crazy when I wrote that using hashes works. I know at
some point in time I tried it and it worked, but I haven't been able to
get that to work in quite a while. I'm considering removing that info
from the documentation. If you get it working, please let me know.
- $wgLDAPRetrievePrefs isn't documented well -- or
it is defaulting to
off. It should say/document something like "Enable to extract CN
attribute / value pairs from LDAP"
Essentially everything in the plugin except using TLS defaults to off
(and I only default to TLS because I'm paranoid). It does pretty much
what it suggests though. It syncs selected preferences from LDAP to
MediaWiki (and optionally the opposite way).
- It is not entirely clear how other mediawiki
settings not defined in
the posixAccount or inetOrgPerson foundation ObjectClasses
for things
such as Skins and Editing preferences should be stored
(semi-overlapping entries in the SQL database side?)
Unfortunately, none of these preferences are pulled/stored from/in LDAP
at the current moment. I'll probably need to make a schema specifically
for MediaWiki for this kind of functionality. The good thing is,
MediaWiki stores a majority of its preferences in a blob in the
database; so, I can just map the needed non-blob preferences to existing
LDAP attributes, and make one new (binary) attribute for the blob in
LDAP. Mapping the preferences back and forth is easy enough, and it done
in a completely overlapping way on the SQL database side.
I will examine these closer during the day today.
~BAS
PS. On that topic of LDAP<->MW prefs, it might be
recommended to use a
wiki table to map SQL columns in mediawiki.wmuser SQL table to LDAP
attributes!
wikidb-# \d mediawiki.mwuser;
Table "mediawiki.mwuser"
Column | Type | Modifiers
--------------------------+--------------------------+--------
----------------------------------------------------------
user_id | integer | not
null default
nextval('mediawiki.user_user_id_seq'::regclass)
user_name | text | not null
user_real_name | text |
user_password | text |
user_newpassword | text |
user_newpass_time | timestamp with time zone |
user_token | character(32) |
user_email | text |
user_email_token | character(32) |
user_email_token_expires | timestamp with time zone |
user_email_authenticated | timestamp with time zone |
user_options | text |
user_touched | timestamp with time zone |
user_registration | timestamp with time zone |
user_editcount | integer |
Indexes:
"mwuser_pkey" PRIMARY KEY, btree (user_id)
"mwuser_user_name_key" UNIQUE, btree (user_name)
"user_email_token_idx" btree (user_email_token)
I've been avoiding adding any tables/columns to the database. I'd like
the plugin to be as non-obtrusive as possible. Preferences are
thankfully easy to map back and forth. I get them from LDAP, and update
the local database. When a user changes their options in the wiki, the
wiki updates LDAP (this part is optional). As mentioned earlier, if I
add a binary attribute to LDAP for mediawiki preferences, that'll kill
most of the issues.
One attribute I desperately need is an external_id attribute in
MediaWiki's user table. I'll probably try again to get this added to the
schema. If I can't get this added, I'll probably make a seperate table
just for that. This is needed for automatic renaming of users when a
username changes in LDAP.
Thanks for the feedback!
V/r,
Ryan Lane