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.
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.
- Group changes would only take effect on login. Users might only log
in once a month.
This is actually fairly normal for most applications. Operating systems work exactly like this. Web SSO systems are also like this. In most web SSO systems, admins have the ability to invalidate a session when they change something for a user. Maybe an interface could be added to invalidate user sessions? It might also be possible to force a group check on sessions older than a specified time.
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.
This could work too, but it could be really expensive depending on the length of the cache.
Can you explain how this implementation might be configured? I'm not terribly familiar with the auto-promote stuff.
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 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
I'm not sure what the difference is between regular and auto-authentication.
Auto-authentication occurs without user interaction, generally because something else has already done the authentication (like the web server); it is currently provided via the UserLoadAfterLoadFromSession hook. Regular authentication is when the user logs in through SpecialUserlogin.
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?
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.
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 would work well as a configuration option.
Most enterprise wiki admins want to ensure users can't pick their own usernames.
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. ;)
Heh. Good point. I think it will likely need to be merged.
Respectfully,
Ryan Lane