On Thu, Mar 25, 2010 at 7:23 PM, Lane, Ryan Ryan.Lane@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@example.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.