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(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
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