Hi,
I'm new on this list but found that the last thread about ExternalAuth [1] dated back from 2010 [2] but I thought it was acceptable to bring up the subject again :)
Stated simply: many AuthPlugin modules stick to using "External Sessions" for SSO purpose and only implement the "UserLoadFromSession" hook. They don't bother implementing a "true" authentication plugin. In such a case [3] this is often incompatible with the use of MW XML API.
ExternalAuth provides a clean API for this which even appears to be used by the MW code-base itself: in SpecialUserlogin.php:
function authenticateUserData() { [...] $this->mExtUser = ExternalUser::newFromName($this->mUsername); [...] $this->mExtUser->authenticate($this->mPassword);
The issue here is that a regular AuthPlugin (a class implementing AuthPlugin) is still needed, at the very least because soon after happens an unconditional call to:
$u->checkPassword().
[ and User::checkPassword() only uses $wgAuth ]
questions: 1) if ExternalAuth->authenticate() succeeded why do we needed User::checkPassword() ? It seems like this is an unneeded duplicated check ?
2) User::checkPassword() makes no consideration for ExternalAuth: it always use $wgAuth and only $wgAuth. => 2.1) does it mean that an AuthPlugin *must* be associated to each ExternalAuth extension ? => 2.2) or does it mean that User::checkPassword() should be fixed to call authenticate() from the proper class (either AuthPlugin or ExternalAuth) ?
If the answer to 2.1 is "yes", then another question arises: 2.1.1) how to access and make use of the ExternalAuth object ($mExtUser in LoginForm) from $wgAuth->authenticate() so that it's not necessary to duplicate code among both classes ?
I attached to pseudo-patch to workaround what is problematic to me.
thank you in advance for your answers.
footnotes:
[1] http://www.mediawiki.org/wiki/ExternalAuth [2] http://article.gmane.org/gmane.science.linguistics.wikipedia.technical/48044 http://article.gmane.org/gmane.science.linguistics.wikipedia.technical/47710 [3] I personally keep in mind the case of AuthDrupal: http://www.mediawiki.org/wiki/AuthDrupal https://drupal.org/project/mediawikiauth https://gitorious.org/drzraf/drupal-mediawiki/commits/custom
The problem is that both AuthPlugin and ExternalAuth are pretty hacked together authentication system and both should be tossed in the garbage and replaced with a legitimately designed authnz system.
*--* *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 9:48 AM, Raphaël Droz raphael.droz@gmail.comwrote:
Hi,
I'm new on this list but found that the last thread about ExternalAuth [1] dated back from 2010 [2] but I thought it was acceptable to bring up the subject again :)
Stated simply: many AuthPlugin modules stick to using "External Sessions" for SSO purpose and only implement the "UserLoadFromSession" hook. They don't bother implementing a "true" authentication plugin. In such a case [3] this is often incompatible with the use of MW XML API.
ExternalAuth provides a clean API for this which even appears to be used by the MW code-base itself: in SpecialUserlogin.php:
function authenticateUserData() { [...] $this->mExtUser = ExternalUser::newFromName($this->mUsername); [...] $this->mExtUser->authenticate($this->mPassword);
The issue here is that a regular AuthPlugin (a class implementing AuthPlugin) is still needed, at the very least because soon after happens an unconditional call to:
$u->checkPassword().
[ and User::checkPassword() only uses $wgAuth ]
questions:
- if ExternalAuth->authenticate() succeeded why do we needed
User::checkPassword() ? It seems like this is an unneeded duplicated check ?
- User::checkPassword() makes no consideration for ExternalAuth: it
always use $wgAuth and only $wgAuth. => 2.1) does it mean that an AuthPlugin *must* be associated to each ExternalAuth extension ? => 2.2) or does it mean that User::checkPassword() should be fixed to call authenticate() from the proper class (either AuthPlugin or ExternalAuth) ?
If the answer to 2.1 is "yes", then another question arises: 2.1.1) how to access and make use of the ExternalAuth object ($mExtUser in LoginForm) from $wgAuth->authenticate() so that it's not necessary to duplicate code among both classes ?
I attached to pseudo-patch to workaround what is problematic to me.
thank you in advance for your answers.
footnotes:
[1] http://www.mediawiki.org/wiki/ExternalAuth [2] http://article.gmane.org/gmane.science.linguistics.wikipedia.technical/48044
http://article.gmane.org/gmane.science.linguistics.wikipedia.technical/47710 [3] I personally keep in mind the case of AuthDrupal: http://www.mediawiki.org/wiki/AuthDrupal https://drupal.org/project/mediawikiauth https://gitorious.org/drzraf/drupal-mediawiki/commits/custom
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
While this patch will support the functionality you are talking about, I believe a better move would be to actually design a proper authentication stack. Some sort of $wgAuthn where you can register authentication layers on a stack. The problem with AuthPlugin and ExternalUser is that they are both too separate from the local authentication process, not to mention both require users have passwords, which is something that is not necessarily true for certain external authentication methods.
*--* *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 11:37 AM, Raphaël raphael.droz@gmail.com wrote:
I've been told that attachment was stripped (was text/x-diff) Using text/plain now.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
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.
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
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
If there are multiple identification sources, what about unicity of usernames? i.e. who is User1 if it exists different people User1@OpenID and User1@RADIUS? the first who registers on the wiki? or is it assumed all User1 are the same people?
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).
Sébastien
Le Fri, 12 Oct 2012 04:35:07 +0200, Tyler Romeo tylerromeo@gmail.com a écrit:
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
On Fri, Oct 12, 2012 at 2:14 AM, Seb35 seb35wikipedia@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@OpenID and 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
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 | tylerromeo@gmail.com
On Fri, Oct 12, 2012 at 2:09 PM, Ryan Lane rlane32@gmail.com wrote:
On Fri, Oct 12, 2012 at 2:14 AM, Seb35 seb35wikipedia@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
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
I'm new on this list but found that the last thread about ExternalAuth [1] dated back from 2010 [2] but I thought it was acceptable to bring up the subject again :)
ExternalAuth should be dropped from core. It isn't maintained, it only supports a single type of authentication that's for something like phpbb, and it requires all of the authentication mechanisms to be in core.
AuthPlugin sucks too, but it's maintained, has lots of extensions, and the extensions can be outside of the core repo.
I'd love for someone to fix our authentication code. AuthPlugin itself isn't terrible, but it needs some refactoring. getCanonicalName, for instance, needs to burn in the fiery depths of hell it came from. Also, core developers tend to ignore that AuthPlugin exists, occasionally. For instance, when the preferences system was rewritten it just dropped all calls to AuthPlugin; that's never been fixed since then.
Bottom line: we need to give a crap about auth plugins in general. It falls by the way side since we don't seem to care much about third party users, though.
- Ryan
I'll work on that over the next week and see if I can come up with a good design to work off of.
*--* *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 2:39 PM, Ryan Lane rlane32@gmail.com wrote:
I'm new on this list but found that the last thread about ExternalAuth
[1]
dated back from 2010 [2] but I thought it was acceptable to bring up the subject again :)
ExternalAuth should be dropped from core. It isn't maintained, it only supports a single type of authentication that's for something like phpbb, and it requires all of the authentication mechanisms to be in core.
AuthPlugin sucks too, but it's maintained, has lots of extensions, and the extensions can be outside of the core repo.
I'd love for someone to fix our authentication code. AuthPlugin itself isn't terrible, but it needs some refactoring. getCanonicalName, for instance, needs to burn in the fiery depths of hell it came from. Also, core developers tend to ignore that AuthPlugin exists, occasionally. For instance, when the preferences system was rewritten it just dropped all calls to AuthPlugin; that's never been fixed since then.
Bottom line: we need to give a crap about auth plugins in general. It falls by the way side since we don't seem to care much about third party users, though.
- Ryan
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
wikitech-l@lists.wikimedia.org