On Thu, Mar 25, 2010 at 11:36 AM, Lane, Ryan
<Ryan.Lane(a)ocean.navo.navy.mil> wrote:
That makes sense. My only concern is that this will
require extension
developers to dive into core to add features they'd normally add to their
own extension. This isn't necessarily a bad thing, as their changes could
benefit everyone.
My goal is to not have this done in extensions at all. Everything
should be in core, ideally. This encourages people to write clean,
reasonable code -- current AuthPlugins duplicate code massively, with
all the problems that entails. Each one supports a different set of
functionality in different ways. Of course, the interface should also
be stable and suitable for extensions, but any ExtAuth plugin in SVN
should be in core, not extensions, IMO.
I add users into the groups; I don't add groups to
users. I do this by:
1. Getting a list of all groups ($user->getAllGroups()), and a list of
groups the user is in ($user->getEffectiveGroups())
2. I iterate through the list of all groups and:
2a. Add the user into the wiki group if they are in the external group
2b. Remove the user from the wiki group if they are in the wiki group, but
no longer in the external group
Effectively, I'm synchronizing the groups every login.
I see. This sounds like it would have a couple of notable issues:
* Special:UserRights would be pretty confusing. Additions and
removals would seem to work, but only until the user next logged in.
* Group changes would only take effect on login. Users might only log
in once a month.
I was thinking that the groups should be implicit, like autoconfirmed,
not explicit. This would require a query to the backend on every
permissions check, however, for linked accounts. Some type of caching
could be optionally used -- maybe just storing the list of groups in
the User object and relying on the fact that that's cached.
Well, the proposal mentions allowing the user to
choose their own username.
That is fine for some extensions (OpenID does this, for instance), and it
may even be useful for the LDAP plugin, but I'd like to ensure the plugin
can choose the name without giving the user an option.
What are the use-cases for this? What sorts of names would you want
to auto-assign? It sounds like this would best be done by exposing
some kind of hook, if it's meant to be for stuff as narrow as
semi-anonymous users. E.g., just have a hook somewhere in account
autocreation that gets passed the User and ExternalUser objects, and
let it choose a name if it likes.
It would be *really* nice if this worked for both
regular, and
auto-authentication, as right now it only works for auto-authentication; I
use this for a semi-anonymous user feature, but it only works for auto-auth:
http://ryandlane.com/blog/2009/06/18/semi-anonymous-users-in-mediawiki-using
-the-ldap-authentication-extension/
I'm not sure what the difference is between regular and auto-authentication.
Actually, no. LDAP usernames are not assumed to be
unique, or stable.
Generally, usernames are based on some combination of a person's name.
People's names can change for various reasons (marriage, legal name change,
etc.). When a person's name changes, their username changes with it. LDAP
entries are assumed to have some unique identifier that is often different
than the username. In the Posix schema, this is uidNumber. In Active
Directory, it is often the Security Identifier (SID), but may also be the
userAlternativeName attribute, which is often the case in smart card
infrastructures.
In the Posix schema, this is guaranteed to be an integer, but in Active
Directory, it will most likely be a string, and can be fairly long.
Okay, now I'm confused. So you're saying that there is no stable,
unique identifier that can be used for querying information about a
user? The only identifier you can use is the username, and that's
unstable? That seems decidedly inconvenient. How is any external
system supposed to integrate with the authentication system if there
are no stable identifiers?
The LDAP plugin detects the external account was
renamed the following way:
On account creation, the plugin records the external ID. On authentication,
the plugin queries LDAP, and gets the username back. If the username is
different than the local account, the plugin renames the account, or blocks
login, which should inform the user to contact the site admin. If the new
username is already taken, the plugin blocks login, which should inform the
user to contact the site admin.
Allowing the user to choose a new name in this situation wouldn't really
make sense, as the extension is assuming the external username matches the
local one. Keeping the name the same is also really problematic for most
organizations using LDAP, as usernames may be re-used.
ExtAuth takes the philosophy that the wiki name may be totally
disconnected from the external name. It would certainly make sense to
allow admins to require them to always be the same, though -- as long
as the backend doesn't have usernames that MediaWiki doesn't allow.
This actually makes me think of another case that
needs to be handled. If
the local database has a username that is the same as a username in LDAP,
but has an external ID recorded that is different from what is in LDAP, the
account in LDAP was likely deleted, but the username was re-used. The plugin
should block login in this situation, so that the admin can rename the
account to something like "Username (deleted)" or "Username (was
<uid>)".
This is important from an auditing perspective.
This is only an issue if backends don't expose a stable user id that's
guaranteed not to be reused. If LDAP really doesn't expose such a
thing, it's crazy :), but I guess it will need to be handled.
All of this assumes that account renaming can be
initiated reliably from an
authentication extension. This isn't currently possible. Why isn't
RenameUser part of core?
I don't know. If it's necessary, it can always be merged to core,
IMO. That's the nice thing about developing in core. ;)
On Thu, Mar 25, 2010 at 12:08 PM, Lane, Ryan
<Ryan.Lane(a)ocean.navo.navy.mil> wrote:
Yeah, I seriously doubt any system is going to have a
unique identifier
longer than 255 characters. I know after this is implemented I'll find some
crazy organization doing this though ;) (like the one that had a user with
over 500 groups - crazy).
If they do, they can ALTER TABLE to change it to a larger size if they like.