>> I'd like to discuss the proposed change to the authentication plugin >> system (http://www.mediawiki.org/wiki/ExternalAuth). As proposed, I >> don't see how I'll be able to keep most of the functionality in the >> LDAP extension. > > It isn't a change, it's an addition. AuthPlugin will be kept > indefinitely, certainly at least until all users in trunk are > obsoleted by equivalent ExtAuth plugins (which may well be never). >
Ah. That's good. I have a good feeling I'll be moving to the new system as I definitely like some of the ideas in it so far. I especially like that the extension will be passed the exact username string typed by the user. I have some open bugs regarding that. >> I don't disagree that policy and implementation shouldn't be mixed, >> but core shouldn't be making all policy decisions. For instance, there >> is an option in the LDAP extension ($wgLDAPDisableAutoCreate) that >> disables auto-creation, but still allows auto-authentication. >> Essentially, it says, if the user exists in LDAP, but not in the local >> directory, don't automatically create the local account. Some >> administrators want to create accounts for users in the wiki locally, >> even though they already have accounts in LDAP. > > First off, if this is desirable for LDAP, it's desirable for other > auth systems too. Therefore, in ExtAuth, this feature would be added > to the core code, *not* individual extensions, so that it could be > used by *all* backends. The LDAP-specific stuff should only deal with > stuff that is *really* specific to LDAP, like connecting to the LDAP > server and mapping MediaWiki auth info to however LDAP stores things. > 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. > Second, I'm not sure what you mean by "disables auto-creation, but > still allows auto-authentication". The user must be authenticated as > *some* user that exists in the MediaWiki database, no? How does > auto-authentication work in this case? > > This might be the same as $wgAutocreatePolicy. The default is > 'login', which autocreates accounts if a user logs in, their auth > information doesn't match any local account, and it does match an > external account. You can also set it to 'never', which never > autocreates local accounts (so they have to be manually linked, which > doesn't work yet); and 'view', which will try to autocreate from > cookies or such if supported by the backend. > Setting it to 'never' would likely fit this situation; I believe this is the correct use case (I've never used this functionality personally). > You mean, you just take the group name strings returned by LDAP and > assign them to the user as MediaWiki groups? That's an interesting > idea, provided there are no conflicts. It would be a lot simpler than > using auto-promote. However, it could cause problems if group names > were weird, like with spaces or something, since a lot of code > probably assumes they look like typical MediaWiki group names. > > Still, I think this is a better approach. Currently this isn't > actually implemented at all in ExtAuth, so it could be changed to the > method you describe easily enough. > 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. This means the admin must choose which groups they want to synchronize by creating them in LocalSettings.php using $wgGroupPermissions, by adding permissions to the group. I do have functionality to add all groups to $wgGroupPermissions (via $wgLDAPGroupsPrevail), so that other extensions can use the groups, but that code is *really* expensive, as sometimes users are in hundreds of groups; I'm unfortunately not exaggerating about the hundreds of groups, I've done a support request where someone had users that had 500+ groups. > > The LDAP plugin can add users to the LDAP database. Is this > also going > > to support that? > > That's a possible feature, although I don't think it's in any of my > design documents. For many backends it would be impractical, but it > would make sense for LDAP. I mostly designed this to allow > authentication on my site's wiki from vBulletin, another web app, so > the design is probably skewed toward that, but I'm pretty sure it's > flexible enough that it could be adjusted to support LDAP well. > Some extensions use this to manage an external database that all their applications use. It is a fairly esoteric feature, but I have users that use it in production. I personally have never used the feature past testing. > > The LDAP plugin allows a user to authenticate with one username, but > > have the username created be something else. This is absolutely a > > must-have for auto-authentication, where a user might authenticate > > with Kerberos or an SSL certificate. If a user authenticates with an > > SSL certificate, their username may be something insane, like a > > numeric ID with special characters. The LDAP plugin would search the > > LDAP directory for another attribute that should be used for the > > username. Notice that you don't necessarily want to treat the > > auto-auth name as an ID either. You may pull both a new > username, and > > a unique ID from the LDAP server; this is an especially likely > > scenario in a large organization, where a user may have a global > > unique ID, but in some places they may have a locally > unique ID (think > > mergers). > > This is part of the design for ExternalAuth, although it hasn't yet > been implemented. It's necessary for any backend that doesn't have > username restrictions as rigid as MediaWiki, or that uses > incomprehensible usernames. Even if you're just authenticating to an > external MediaWiki, it's necessary to resolve conflicts. (In > particular, this is necessary for vBulletin, since that permits > characters like / in names, but it's not so essential, since most > names don't have them -- which is why it's not implemented yet.) > 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. 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/ > > There are situations where newFromId( $id ) and getId() won't work. > > Active Directory (AD) is a case where it is unlikely to > work for most > > people. By default AD does not allow anonymous searches. > There are two > > ways to handle this: > > > > 1. Use a proxy agent (AD administrators *hate* this) > > 2. Bind as the user first > > > > In the second case, newFromId( $id ), and getId() will only work if > > authenticate( $password ) is called first. In fact, many things > > require the user to be authenticated before another action > can happen. > > From the LDAP server's perspective, MediaWiki *is* the user binding. > > From ExternalAuth's perspective, an "id" can be any unique, stable > identifier. It's used to store the information "MediaWiki user 13099 > is associated to external user 32769". A "username" is expected to be > something human-readable, which is actually used for login, but which > may change from time to time (due to renaming). id's are stored in a > varchar(255) and are not required to be numeric. > > In particular, I think LDAP could just use an id equal to the > username, since LDAP usernames are supposed to be stable, right? > 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. > > A few things I'd really like to see fixed with any new system are: > > > > 1. Extensions being able to display error messages (bug 16524) > > This sounds like a good idea. An implementation idea would be to add > a new method ExternalUser::getAuthenticationErrors(), like > Title::getUserPermissionsErrors(), and use that in core code instead > of authenticate(). The new method could wrap authenticate() in the > base class, so classes that didn't need such fancy control could still > just use authenticate(). > That sounds like a good idea. > > 2. Ability to rename a local account when the external > account is renamed > > Sounds like a good idea, but how would you detect that the external > account was renamed? Would you expect the external auth source to > push this info to MediaWiki, or should MediaWiki detect it when the > user next logs in? How should MediaWiki detect it -- remember the > external username, and update the local one if the external one is > different from what was remembered? Presumably it would just abort > silently if there's some conflict (e.g., new name not usable by > MediaWiki, or already taken). > > The current ExtAuth implementation only stores the foreign id locally, > not the name. If the external name changes, and the new external name > isn't taken locally, you can log in to MediaWiki using either the new > or old name, IIRC -- if you try the new one, it will authenticate you > as the external user, then notice that that already has a local > account and log you in as that. But your MediaWiki username will > remain the same as the old name unless you're renamed on MediaWiki. > This works for now, but would be nice to change. > I implemented this in my extension, and tested it, but never publisized it, since it relied on the rename user extension, and I wasn't totally sure I wasn't going to cause massive data corruption if there was some incompatibility I didn't foresee. 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. 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. 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? User renaming, blocking, etc. should likely be a configurable option, as some features (such as the semi-anonymous example above), assume the username to be different. > > 3. Local group name size increased in the schema (bug 11057) so that > > all external groups can be synced properly > > I forgot that MediaWiki group names have to be so short. Maybe > autopromote is a better idea after all for backends that might have > long group names. But that should be fixable, anyway, I hope. > Well, from the bug, it looks like the schema was set to be modified to have 255 character names, but it never happened. It is really unlikely for groups to be longer than 255 characters. Respectfully, Ryan Lane
_______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
