On Thu, Mar 25, 2010 at 7:23 PM, Lane, Ryan
<Ryan.Lane(a)ocean.navo.navy.mil> wrote:
This wouldn't be an issue if it updated the
external database when adding
users. Some backends may not support this... This may be one spot where
policy should be decided by the backend.
Policy should still be decided in core, but backends would just ignore
configuration they don't support. For instance, an autocreate setting
of 'view' is unlikely to be supported by backends that don't have
cookies (or similar) to autocreate from, so it should be treated as
'login'.
This could work too, but it could be really expensive
depending on the
length of the cache.
Yes, it depends. If you're authenticating to some MySQL-based forum
on the same server, then it's typically just one extra query per view,
which is no big deal. In other situations it might be different.
Can you explain how this implementation might be
configured? I'm not
terribly familiar with the auto-promote stuff.
I don't think autopromote is a good way to go, actually, since it's
hard to configure. I think your idea of adding the groups magically
is a better one overall. The way it would work is we'd modify
User::getEffectiveGroups() to retrieve a list of all external groups
(if the user is linked to an external account), then add those to the
list of returned groups. It shouldn't be a big issue if someone has
500 groups in this scheme -- although it will make
[[Special:Preferences]] a little long. :) So we could just do what
you do and only return groups that have keys set in
$wgGroupPermissions.
It isn't as narrow as that. The LDAP extension may
use it for any form of
auto-auth, like Kerberos or SSL authentication, where the username provided
is something odd like "ryan.lane(a)example.org".org", or
"Example_Organization__RYAN.LANE.12345". In those cases, the MediaWiki admin
probably wants to use an attribute like sAMAccountName (for AD), or uid
(which is actually the username, not the uid, in the Posix schema).
I do actually handle this via a hook in my extension, but that hook passes
the user's LDAP object to pull attributes from. See this smartcard
configuration as an example:
http://www.mediawiki.org/wiki/Extension:LDAP_Authentication/Smartcard_Config
uration_Examples#Basic_LDAP_extension_configuration
We could have a hook that gets passed the ExternalUser object, and add
a getProperty() method or such to it. We could also have a
$wgExternalAuthUsePropertyForName or something to set the name to a
particular property instead of username.
No. I'm saying there is a stable identifier that
is generally not used for
authentication. A username is a user friendly identifier that is unique, but
not stable. Generally, you integrate with the user friendly identifier, and
keep track of the stable identifier, in case the user friendly one changes.
Hmm. That means you can't actually retrieve any data about the user
at all if they don't enter their password, right? That would explain
why nothing would update until the next login, because you can't
retrieve the new data until the next login. So LDAP will have to
store a lot of things that could just be retrieved on demand with a
simple database backend, for instance.
We could add a eu_cache column that's just a blob that backends can
throw anything in that they need to cache. Then the LDAP id could be
used for eu_external_id, and anything that relies on creating an
ExternalUser from id will use the cached data. At a minimum,
usergroups would need to be cached, it sounds like.