I like most of the requirements that Tyler and Danial have listed. There are a couple of things that I didn't clearly see accounted for, so I wanted to make sure whatever you come up with accounts for these:
- Extensions / tools need to hook into all the identity pieces, so a tool like AbuseFilter can block users logging in with an external systems, and ConfirmEdit can inject captchas if someone is trying to brute force a login. - Whatever we do will need to keep most of the existing interfaces. We can't merge any updates that would break CentralAuth, LDAP, OathAuth, or the upcoming OAuth, without a clear upgrade plan and time to put those pieces in place without downtime. - Single and Multi-factor authentication support - Identity merging (if someone authenticates with OpenID, then later creates a wiki account, make sure we can merge the concept of that user)
On Thu, Oct 11, 2012 at 7:35 PM, Tyler Romeo tylerromeo@gmail.com wrote:
I don't think it's possible, or even preferable, to do a rework. AuthPlugin is fundamentally flawed in its design and ExternalAuth is lacking in a number of major features. What we need is a full-fledged authnz system. Attached is a basic outline I've been developing recently.
The idea is a very rough draft, but it would allow:
- Multiple authentication sources working in tandem
- A separation of policy and implementation
- A separation of authentication and authorization
- A separation of MediaWiki logic and framework logic
- An arbitrary list of "user properties", so that frameworks can store
more than just email and real name if necessary
- An arbitrary "authentication data" array, so frameworks are not
required to stick to username/password.
- Permission-based blocking and role-based permissions
This could be used in combination with the FormSpecialPage-based Special:Userlogin and Special:ChangePassword that are currently in Gerrit to allow more comprehensive authnz frameworks. *--* *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerromeo@gmail.com
On Thu, Oct 11, 2012 at 7:48 PM, Ryan Lane rlane32@gmail.com wrote:
On Thu, Oct 11, 2012 at 4:33 PM, Daniel Friesen daniel@nadir-seen-fire.com wrote:
I was thinking about this recently too. Though I started thinking from
the
login form perspective.
Things we should have:
- Good build-in support for both single-authentication (everyone is in
the
user database, or everyone in ldap, etc...) and multi-authentication
(some
users are local, some are OAuth, others may be LDAP) and also the possibility of multiple auth types for one user.
- A real abstract login form that lets extensions and auth systems simply
add fields to the login/creation form without having to re-implement it
and
not work with other similar extensions. -- Perhaps also some meta information from auth plugins that let us say
on
the login form that a wiki is using LDAP or something.
- Explicit support for auth systems using something other than the
username.
- Real support for auth systems involving a 3rd party. ie: Involving
redirects such as OAuth, OpenID, and simple 3rd party login where the
login
link directs you to the login page of some forum, you get sent back, and somehow the extension knows what the session is.
- Login form support for multiple authentication systems on the same
wiki,
incl. support for OAuth and OpenID like logins.
That last one was the tricky one to figure out.
Whatever is done, can it please be done as a refactor, rather than a rewrite?
- 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