The problem is that the current system cannot handle multiple authentication or authorization sources at once. Furthermore, the system for granting and blocking permissions is ridiculously crude. This new system I proposed would allow more flexibility and security for authentication and authorization, something that MediaWiki needs. If implemented, we can wrap AuthPlugin in the new system and then deprecate it.
@Seb35 - What I'm thinking is that, like the current ExternalAuth, an external user will be linked to local users. The only time there will be a conflict is if somehow a user is able to successfully authenticate to two different services separately and each has a different linked local account, which would be rare because it implies the user has and used authentication info for two separate accounts simultaneously. The only problem would be figuring out how to link already established local accounts to other external services as they are added in, e.g., a user who registered using OpenID and wants to add their LDAP account. @Chris - Agreed on all points. In the idea I sent out, there is no such thing as a "password". There is just an array of "authentication data", which is raw data captured from the authentication point. This is one advantage over AuthPlugin, which requires a username/password scheme. And I believe, if we were to do this, we could have an AuthPluginProvider, which would wrap around $wgAuth for backwards compatibility. *--* *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerro...@gmail.com On Fri, Oct 12, 2012 at 2:09 PM, Ryan Lane <rlan...@gmail.com> wrote: > On Fri, Oct 12, 2012 at 2:14 AM, Seb35 <seb35wikipe...@gmail.com> wrote: > > If there are multiple identification sources, what about unicity of > > usernames? i.e. who is User1 if it exists different people User1@OpenIDand > > User1@RADIUS? the first who registers on the wiki? or is it assumed all > > User1 are the same people? > > > > Some kind of pipelining system, or pam like system would allow users > to specify which service is used for identity, authentication, and > authorization. That said, systems like this are pretty complicated to > configure for end-users. Most auth extensions are already difficult to > configure. Very few people need this level of flexibility. > > I think this could be accomplished by hooks easily enough. I have 3 > authentication plugins working in unison on labsconsole.wikimedia.org > (LdapAuthentication, OATHAuth, and OpenStackManager) plus ConfirmEdit > (which requires a captcha for account creation). I'm using hooks to > handle all of this. I could add on Kerberos, OpenID or some other form > of auto-authentication if I liked without much issue. > > The current AuthPlugin system works for the most part. It just needs > to be cleaned up and refactored. Its major issue is that core's > authn/z system is really, really shitty and isn't properly maintained. > > If there's a rewrite it will very likely die like ExternalAuth. I have > no plans on rewriting any of my authentication extensions from > scratch, and I've written (or fixed) the majority of the auth > extensions actually used. > > > And if there is a rewrite of the auth, I want just point out that aside > > authentications like OpenID, OAuth, local DB, there are also some > > profesionnal authentication backend like Shibboleth, RADIUS, CAS, > Kerberos > > that should be taken into account for enterprise wikis (it should be > generic > > enough for these types of authentication). > > > > The current system can handle all of these already. > > - Ryan > > _______________________________________________ > Wikitech-l mailing list > Wikitech-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
