Hi, it's been almost 4 years since we came with the idea of implementing an OAuth to mediawiki. I think it's time to start. Question now is if it should be a part of core or extension for mediawiki. I myself would rather make it as extension, since there is probably no use for most of installations, except for large wikis.
Quote: OAuth provides a standard protocol to negotiate secure access tokens and to provide third-party tools (web or client) with granular access to private resources. This protocol does not reveal usernames or passwords to the third-party tool. Offering OAuth based authorization on Mediawiki wiki's will increase the reusability of its data and spur the creation of an ecosystem of app's around Mediawiki.
Is there anyone who is willing to help with this? If there is no one interested in this, or no comments, I would start a new extension called OAuth, which only purpose would be to enable this feature in mediawiki.
Awesome plans. I lack time, PHP experience, and experience with the wikimedia codebase to help you in a more meaningful way (as in: help you write it). nonetheless, very good idea, and very useful functionality
On Tue, Mar 13, 2012 at 1:50 PM, Petr Bena benapetr@gmail.com wrote:
Hi, it's been almost 4 years since we came with the idea of implementing an OAuth to mediawiki. I think it's time to start. Question now is if it should be a part of core or extension for mediawiki. I myself would rather make it as extension, since there is probably no use for most of installations, except for large wikis.
Quote: OAuth provides a standard protocol to negotiate secure access tokens and to provide third-party tools (web or client) with granular access to private resources. This protocol does not reveal usernames or passwords to the third-party tool. Offering OAuth based authorization on Mediawiki wiki's will increase the reusability of its data and spur the creation of an ecosystem of app's around Mediawiki.
Is there anyone who is willing to help with this? If there is no one interested in this, or no comments, I would start a new extension called OAuth, which only purpose would be to enable this feature in mediawiki.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
This isn't something that can be implemented as an extension, it needs to be in core. This goes way beyond just allowing a user to log in to a site with their MediaWiki account, it needs full integration with our permissions and API to be of any use.
On Tue, Mar 13, 2012 at 8:50 AM, Petr Bena benapetr@gmail.com wrote:
Hi, it's been almost 4 years since we came with the idea of implementing an OAuth to mediawiki. I think it's time to start. Question now is if it should be a part of core or extension for mediawiki. I myself would rather make it as extension, since there is probably no use for most of installations, except for large wikis.
Quote: OAuth provides a standard protocol to negotiate secure access tokens and to provide third-party tools (web or client) with granular access to private resources. This protocol does not reveal usernames or passwords to the third-party tool. Offering OAuth based authorization on Mediawiki wiki's will increase the reusability of its data and spur the creation of an ecosystem of app's around Mediawiki.
Is there anyone who is willing to help with this? If there is no one interested in this, or no comments, I would start a new extension called OAuth, which only purpose would be to enable this feature in mediawiki.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Hi,
Of course, I am following the proposal at https://www.mediawiki.org/wiki/OAuth, even there is mentioned that it's not clear if it should be extension or in core. In fact I don't see a reason why it couldn't be extension. You can extends api's from extension and even access the permission definitions.
On Tue, Mar 13, 2012 at 3:09 PM, John Du Hart compwhizii@gmail.com wrote:
This isn't something that can be implemented as an extension, it needs to be in core. This goes way beyond just allowing a user to log in to a site with their MediaWiki account, it needs full integration with our permissions and API to be of any use.
On Tue, Mar 13, 2012 at 8:50 AM, Petr Bena benapetr@gmail.com wrote:
Hi, it's been almost 4 years since we came with the idea of implementing an OAuth to mediawiki. I think it's time to start. Question now is if it should be a part of core or extension for mediawiki. I myself would rather make it as extension, since there is probably no use for most of installations, except for large wikis.
Quote: OAuth provides a standard protocol to negotiate secure access tokens and to provide third-party tools (web or client) with granular access to private resources. This protocol does not reveal usernames or passwords to the third-party tool. Offering OAuth based authorization on Mediawiki wiki's will increase the reusability of its data and spur the creation of an ecosystem of app's around Mediawiki.
Is there anyone who is willing to help with this? If there is no one interested in this, or no comments, I would start a new extension called OAuth, which only purpose would be to enable this feature in mediawiki.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
-- John
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
My idea is that it would work like on facebook, a special page would open from the external tool (in a separate browser), example:
Application "MOO" wants to access the site using your account, do you want to allow it to perform these operations:
- Read - Edit - Rollback
Yes, I want to allow MOO to access the site using my account
No
If user pick yes, the token is being sent back to application which then use it to perform various api's etc The application would define what kind of access it would need to use and which kind of authentication (token / key / certificate) it wants to use
On Tue, Mar 13, 2012 at 3:13 PM, Petr Bena benapetr@gmail.com wrote:
Hi,
Of course, I am following the proposal at https://www.mediawiki.org/wiki/OAuth, even there is mentioned that it's not clear if it should be extension or in core. In fact I don't see a reason why it couldn't be extension. You can extends api's from extension and even access the permission definitions.
On Tue, Mar 13, 2012 at 3:09 PM, John Du Hart compwhizii@gmail.com wrote:
This isn't something that can be implemented as an extension, it needs to be in core. This goes way beyond just allowing a user to log in to a site with their MediaWiki account, it needs full integration with our permissions and API to be of any use.
On Tue, Mar 13, 2012 at 8:50 AM, Petr Bena benapetr@gmail.com wrote:
Hi, it's been almost 4 years since we came with the idea of implementing an OAuth to mediawiki. I think it's time to start. Question now is if it should be a part of core or extension for mediawiki. I myself would rather make it as extension, since there is probably no use for most of installations, except for large wikis.
Quote: OAuth provides a standard protocol to negotiate secure access tokens and to provide third-party tools (web or client) with granular access to private resources. This protocol does not reveal usernames or passwords to the third-party tool. Offering OAuth based authorization on Mediawiki wiki's will increase the reusability of its data and spur the creation of an ecosystem of app's around Mediawiki.
Is there anyone who is willing to help with this? If there is no one interested in this, or no comments, I would start a new extension called OAuth, which only purpose would be to enable this feature in mediawiki.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
-- John
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
In.
-Jeff
On Mar 13, 2012, at 8:50 AM, Petr Bena wrote:
Hi, it's been almost 4 years since we came with the idea of implementing an OAuth to mediawiki. I think it's time to start. Question now is if it should be a part of core or extension for mediawiki. I myself would rather make it as extension, since there is probably no use for most of installations, except for large wikis.
Quote: OAuth provides a standard protocol to negotiate secure access tokens and to provide third-party tools (web or client) with granular access to private resources. This protocol does not reveal usernames or passwords to the third-party tool. Offering OAuth based authorization on Mediawiki wiki's will increase the reusability of its data and spur the creation of an ecosystem of app's around Mediawiki.
Is there anyone who is willing to help with this? If there is no one interested in this, or no comments, I would start a new extension called OAuth, which only purpose would be to enable this feature in mediawiki.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Exporting authentication from Mediawiki by OAuth is probably both acceptable and interesting, even if OAuth is said to give a rather weak security. It could be that people are a bit confused about OAuth vs OpenID.
In some of the projects where I've been involved the problem is not about exporting authentication, but more about how to log on to a Mediawiki-powered site from an other central site doing identity federation. The existing extensions don't handle this very well.
Could it be possible to start a work on both importing and exporting identity, authentication and authorization, perhaps focusing on both SAML and OAuth? For serious use it seems to me that SAML is more important than OAuth, while the later is more widespread in social networks.
John
On Tue, Mar 13, 2012 at 3:18 PM, Jeff Ferland jeff@storyinmemo.com wrote:
In.
-Jeff
On Mar 13, 2012, at 8:50 AM, Petr Bena wrote:
Hi, it's been almost 4 years since we came with the idea of implementing an OAuth to mediawiki. I think it's time to start. Question now is if it should be a part of core or extension for mediawiki. I myself would rather make it as extension, since there is probably no use for most of installations, except for large wikis.
Quote: OAuth provides a standard protocol to negotiate secure access tokens and to provide third-party tools (web or client) with granular access to private resources. This protocol does not reveal usernames or passwords to the third-party tool. Offering OAuth based authorization on Mediawiki wiki's will increase the reusability of its data and spur the creation of an ecosystem of app's around Mediawiki.
Is there anyone who is willing to help with this? If there is no one interested in this, or no comments, I would start a new extension called OAuth, which only purpose would be to enable this feature in mediawiki.
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
Of course it's possible to start work on both, if there is enough developers who are willing to work on it. SAML is something else than OAuth, which solves the problem with "trustworth" of 3rd application (prevent account from being compromised by 3rd application which ask for user password), SAML does it too at some point, but it rather secure the exchange of credentials between two trustworthy systems. The problem we are facing now, is that mediawiki has no possibility of authenticating user other than asking for a password. And even if developers of application which uses mediawiki don't want their application to ask for a password, they have to and since making a web applications which do that, isn't allowed by wmf (such sites are likely to be blocked from accessing wikimedia servers) it totally block development of any web application which could work with sites hosted by wikimedia.
On Tue, Mar 13, 2012 at 4:10 PM, John Erling Blad jeblad@gmail.com wrote:
Exporting authentication from Mediawiki by OAuth is probably both acceptable and interesting, even if OAuth is said to give a rather weak security. It could be that people are a bit confused about OAuth vs OpenID.
In some of the projects where I've been involved the problem is not about exporting authentication, but more about how to log on to a Mediawiki-powered site from an other central site doing identity federation. The existing extensions don't handle this very well.
Could it be possible to start a work on both importing and exporting identity, authentication and authorization, perhaps focusing on both SAML and OAuth? For serious use it seems to me that SAML is more important than OAuth, while the later is more widespread in social networks.
John
On Tue, Mar 13, 2012 at 3:18 PM, Jeff Ferland jeff@storyinmemo.com wrote:
In.
-Jeff
On Mar 13, 2012, at 8:50 AM, Petr Bena wrote:
Hi, it's been almost 4 years since we came with the idea of implementing an OAuth to mediawiki. I think it's time to start. Question now is if it should be a part of core or extension for mediawiki. I myself would rather make it as extension, since there is probably no use for most of installations, except for large wikis.
Quote: OAuth provides a standard protocol to negotiate secure access tokens and to provide third-party tools (web or client) with granular access to private resources. This protocol does not reveal usernames or passwords to the third-party tool. Offering OAuth based authorization on Mediawiki wiki's will increase the reusability of its data and spur the creation of an ecosystem of app's around Mediawiki.
Is there anyone who is willing to help with this? If there is no one interested in this, or no comments, I would start a new extension called OAuth, which only purpose would be to enable this feature in mediawiki.
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
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Am 13.03.2012 16:10, schrieb John Erling Blad:
Exporting authentication from Mediawiki by OAuth is probably both acceptable and interesting, even if OAuth is said to give a rather weak security. It could be that people are a bit confused about OAuth vs OpenID.
Please don't touch or change https://www.mediawiki.org/wiki/Extension:OpenID . It is stable.
On Tue, Mar 13, 2012 at 8:10 AM, John Erling Blad jeblad@gmail.com wrote:
Exporting authentication from Mediawiki by OAuth is probably both acceptable and interesting, even if OAuth is said to give a rather weak security. It could be that people are a bit confused about OAuth vs OpenID.
In some of the projects where I've been involved the problem is not about exporting authentication, but more about how to log on to a Mediawiki-powered site from an other central site doing identity federation. The existing extensions don't handle this very well.
Could it be possible to start a work on both importing and exporting identity, authentication and authorization, perhaps focusing on both SAML and OAuth? For serious use it seems to me that SAML is more important than OAuth, while the later is more widespread in social networks.
So, since we're discussing SAML and OAuth and OpenID, and such, I should mention this:
It supports SAML, OpenID, OAuth, it's extendable and it supports multiple backends (LDAP, MySQL, etc). It is also localizable.
- Ryan
So, since we're discussing SAML and OAuth and OpenID, and such, I should mention this:
It supports SAML, OpenID, OAuth, it's extendable and it supports multiple backends (LDAP, MySQL, etc). It is also localizable.
- Ryan
That one is interesting for the Norwegian Wikipedia community as it would make it possible to log into Wikipedia from the identity federation system used in Norwegian schools. That is we would be able to block individual students that are trolling instead of whole schools.
John
On Tue, Mar 13, 2012 at 3:32 PM, John Erling Blad jeblad@gmail.com wrote:
So, since we're discussing SAML and OAuth and OpenID, and such, I should mention this:
It supports SAML, OpenID, OAuth, it's extendable and it supports multiple backends (LDAP, MySQL, etc). It is also localizable.
- Ryan
That one is interesting for the Norwegian Wikipedia community as it would make it possible to log into Wikipedia from the identity federation system used in Norwegian schools. That is we would be able to block individual students that are trolling instead of whole schools.
Good to know. :)
There's really two separate things that these systems can do.
The classic OAuth scenario is like this:
site A: Wikipedia user A site B: Huggle
Site B initiates a special login on site A using a shared secret; on success, site A passes back authentication tokens to site B which verify that user A allowed site B access.
Site B then uses those tokens when it accesses site A, in place of a username/password directly.
OpenID, SAML, etc seem to be more appropriate for this scenario:
site A: Wikipedia site B: University user B
These systems allow user B to verify their identity to site A; one possibility is to use this to associate a user A' with the remote user B, letting you use the remote ID verification in place of a local password authentication. (This is what our current OpenID extension does, basically.)
These are, IMO, totally separate use cases and I'm not sure they should be treated the same.
-- brion
There's really two separate things that these systems can do.
The classic OAuth scenario is like this:
site A: Wikipedia user A site B: Huggle
Site B initiates a special login on site A using a shared secret; on success, site A passes back authentication tokens to site B which verify that user A allowed site B access.
Site B then uses those tokens when it accesses site A, in place of a username/password directly.
OpenID, SAML, etc seem to be more appropriate for this scenario:
site A: Wikipedia site B: University user B
These systems allow user B to verify their identity to site A; one possibility is to use this to associate a user A' with the remote user B, letting you use the remote ID verification in place of a local password authentication. (This is what our current OpenID extension does, basically.)
These are, IMO, totally separate use cases and I'm not sure they should be treated the same.
The Extension:OpenID can be used for both cases ( given, that you set $wgOpenIDClientOnly = false; ) https://www.mediawiki.org/wiki/Extension:OpenID .
"The extension makes a MediaWiki installation OpenID 2.0-aware and lets users log in using their OpenID identity - a special URL - instead of (or as an alternative to) standard username/password log in. In that way, the MediaWiki acts as Relying part (RP) = OpenID consumer.[1]
*As an option, it also allows the*_*MediaWiki to act as OpenID provider*, _so that users with an account on that wiki can use their userpage URL as OpenID with which they can log in to other OpenID-aware web sites."
set $wgOpenIDClientOnly = false; if you want this
Tom.
Just as an idea, would it be possible for Wikimedia Foundation to establish some kind of joint project with the SimpleSAMLphp-folks? Those are basically Uninett, which is FEIDE, which is those that handle identity federation for lots of the Norwegian schools, colleges and universities.. The SimpleSAML solution is in use in several other projects/countries, not sure whats the current status. The platform for FEIDE is also in use in several other countries so if the log on problems in Norway are solved other countries will be able to use the same solution.
Note also that OAuth 2.0 seems to be supported. https://rnd.feide.no/2012/03/08/releasing-a-oauth-2-0-javascript-library/
In april this year there is a conference GoOpen 2012 (http://www.goopen.no/) in Oslo and some folks from Wikimedia Foundation is there, perhaps some folks from Uninett too? Could it be possible for interested people to sit down and discuss wetter a joint project is possible? Uninett is hiring for SimpleSAML development and that could be interesting too!
John
On Wed, Mar 14, 2012 at 12:13 AM, Thomas Gries mail@tgries.de wrote:
There's really two separate things that these systems can do.
The classic OAuth scenario is like this:
site A: Wikipedia user A site B: Huggle
Site B initiates a special login on site A using a shared secret; on success, site A passes back authentication tokens to site B which verify that user A allowed site B access.
Site B then uses those tokens when it accesses site A, in place of a username/password directly.
OpenID, SAML, etc seem to be more appropriate for this scenario:
site A: Wikipedia site B: University user B
These systems allow user B to verify their identity to site A; one possibility is to use this to associate a user A' with the remote user B, letting you use the remote ID verification in place of a local password authentication. (This is what our current OpenID extension does, basically.)
These are, IMO, totally separate use cases and I'm not sure they should be treated the same.
The Extension:OpenID can be used for both cases ( given, that you set $wgOpenIDClientOnly = false; ) https://www.mediawiki.org/wiki/Extension:OpenID .
"The extension makes a MediaWiki installation OpenID 2.0-aware and lets users log in using their OpenID identity - a special URL - instead of (or as an alternative to) standard username/password log in. In that way, the MediaWiki acts as Relying part (RP) = OpenID consumer.[1]
*As an option, it also allows the*_*MediaWiki to act as OpenID provider*, _so that users with an account on that wiki can use their userpage URL as OpenID with which they can log in to other OpenID-aware web sites."
set $wgOpenIDClientOnly = false; if you want this
Tom.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
So, right now a question is if it's supposed to be implemented as extension or in core, or both (in case extension can't be created now, updated core do that it's possible).
I would rather make is as extension since there is a little benefit for most of mediawiki users in having this feature. I think it's better to keep only necessary stuff inside core and keep extra stuff as extensions.
Is there any objection against implementing it as extension? Thanks
On Wed, Mar 14, 2012 at 12:49 AM, John Erling Blad jeblad@gmail.com wrote:
Just as an idea, would it be possible for Wikimedia Foundation to establish some kind of joint project with the SimpleSAMLphp-folks? Those are basically Uninett, which is FEIDE, which is those that handle identity federation for lots of the Norwegian schools, colleges and universities.. The SimpleSAML solution is in use in several other projects/countries, not sure whats the current status. The platform for FEIDE is also in use in several other countries so if the log on problems in Norway are solved other countries will be able to use the same solution.
Note also that OAuth 2.0 seems to be supported. https://rnd.feide.no/2012/03/08/releasing-a-oauth-2-0-javascript-library/
In april this year there is a conference GoOpen 2012 (http://www.goopen.no/) in Oslo and some folks from Wikimedia Foundation is there, perhaps some folks from Uninett too? Could it be possible for interested people to sit down and discuss wetter a joint project is possible? Uninett is hiring for SimpleSAML development and that could be interesting too!
John
On Wed, Mar 14, 2012 at 12:13 AM, Thomas Gries mail@tgries.de wrote:
There's really two separate things that these systems can do.
The classic OAuth scenario is like this:
site A: Wikipedia user A site B: Huggle
Site B initiates a special login on site A using a shared secret; on success, site A passes back authentication tokens to site B which verify that user A allowed site B access.
Site B then uses those tokens when it accesses site A, in place of a username/password directly.
OpenID, SAML, etc seem to be more appropriate for this scenario:
site A: Wikipedia site B: University user B
These systems allow user B to verify their identity to site A; one possibility is to use this to associate a user A' with the remote user B, letting you use the remote ID verification in place of a local password authentication. (This is what our current OpenID extension does, basically.)
These are, IMO, totally separate use cases and I'm not sure they should be treated the same.
The Extension:OpenID can be used for both cases ( given, that you set $wgOpenIDClientOnly = false; ) https://www.mediawiki.org/wiki/Extension:OpenID .
"The extension makes a MediaWiki installation OpenID 2.0-aware and lets users log in using their OpenID identity - a special URL - instead of (or as an alternative to) standard username/password log in. In that way, the MediaWiki acts as Relying part (RP) = OpenID consumer.[1]
*As an option, it also allows the*_*MediaWiki to act as OpenID provider*, _so that users with an account on that wiki can use their userpage URL as OpenID with which they can log in to other OpenID-aware web sites."
set $wgOpenIDClientOnly = false; if you want this
Tom.
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
Sorry, few typos:
So, right now a question is if it's supposed to be implemented as extension or in core, or both (in case extension can't be created now, update core so that it's possible).
^ that's what I was about to say
On Fri, Mar 16, 2012 at 3:17 PM, Petr Bena benapetr@gmail.com wrote:
So, right now a question is if it's supposed to be implemented as extension or in core, or both (in case extension can't be created now, updated core do that it's possible).
I would rather make is as extension since there is a little benefit for most of mediawiki users in having this feature. I think it's better to keep only necessary stuff inside core and keep extra stuff as extensions.
Is there any objection against implementing it as extension? Thanks
On Wed, Mar 14, 2012 at 12:49 AM, John Erling Blad jeblad@gmail.com wrote:
Just as an idea, would it be possible for Wikimedia Foundation to establish some kind of joint project with the SimpleSAMLphp-folks? Those are basically Uninett, which is FEIDE, which is those that handle identity federation for lots of the Norwegian schools, colleges and universities.. The SimpleSAML solution is in use in several other projects/countries, not sure whats the current status. The platform for FEIDE is also in use in several other countries so if the log on problems in Norway are solved other countries will be able to use the same solution.
Note also that OAuth 2.0 seems to be supported. https://rnd.feide.no/2012/03/08/releasing-a-oauth-2-0-javascript-library/
In april this year there is a conference GoOpen 2012 (http://www.goopen.no/) in Oslo and some folks from Wikimedia Foundation is there, perhaps some folks from Uninett too? Could it be possible for interested people to sit down and discuss wetter a joint project is possible? Uninett is hiring for SimpleSAML development and that could be interesting too!
John
On Wed, Mar 14, 2012 at 12:13 AM, Thomas Gries mail@tgries.de wrote:
There's really two separate things that these systems can do.
The classic OAuth scenario is like this:
site A: Wikipedia user A site B: Huggle
Site B initiates a special login on site A using a shared secret; on success, site A passes back authentication tokens to site B which verify that user A allowed site B access.
Site B then uses those tokens when it accesses site A, in place of a username/password directly.
OpenID, SAML, etc seem to be more appropriate for this scenario:
site A: Wikipedia site B: University user B
These systems allow user B to verify their identity to site A; one possibility is to use this to associate a user A' with the remote user B, letting you use the remote ID verification in place of a local password authentication. (This is what our current OpenID extension does, basically.)
These are, IMO, totally separate use cases and I'm not sure they should be treated the same.
The Extension:OpenID can be used for both cases ( given, that you set $wgOpenIDClientOnly = false; ) https://www.mediawiki.org/wiki/Extension:OpenID .
"The extension makes a MediaWiki installation OpenID 2.0-aware and lets users log in using their OpenID identity - a special URL - instead of (or as an alternative to) standard username/password log in. In that way, the MediaWiki acts as Relying part (RP) = OpenID consumer.[1]
*As an option, it also allows the*_*MediaWiki to act as OpenID provider*, _so that users with an account on that wiki can use their userpage URL as OpenID with which they can log in to other OpenID-aware web sites."
set $wgOpenIDClientOnly = false; if you want this
Tom.
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
Some updates on this? Is WMF or someone going to work on this or it's waiting for someone to start?
On Fri, Mar 16, 2012 at 3:19 PM, Petr Bena benapetr@gmail.com wrote:
Sorry, few typos:
So, right now a question is if it's supposed to be implemented as extension or in core, or both (in case extension can't be created now, update core so that it's possible).
^ that's what I was about to say
On Fri, Mar 16, 2012 at 3:17 PM, Petr Bena benapetr@gmail.com wrote:
So, right now a question is if it's supposed to be implemented as extension or in core, or both (in case extension can't be created now, updated core do that it's possible).
I would rather make is as extension since there is a little benefit for most of mediawiki users in having this feature. I think it's better to keep only necessary stuff inside core and keep extra stuff as extensions.
Is there any objection against implementing it as extension? Thanks
On Wed, Mar 14, 2012 at 12:49 AM, John Erling Blad jeblad@gmail.com wrote:
Just as an idea, would it be possible for Wikimedia Foundation to establish some kind of joint project with the SimpleSAMLphp-folks? Those are basically Uninett, which is FEIDE, which is those that handle identity federation for lots of the Norwegian schools, colleges and universities.. The SimpleSAML solution is in use in several other projects/countries, not sure whats the current status. The platform for FEIDE is also in use in several other countries so if the log on problems in Norway are solved other countries will be able to use the same solution.
Note also that OAuth 2.0 seems to be supported. https://rnd.feide.no/2012/03/08/releasing-a-oauth-2-0-javascript-library/
In april this year there is a conference GoOpen 2012 (http://www.goopen.no/) in Oslo and some folks from Wikimedia Foundation is there, perhaps some folks from Uninett too? Could it be possible for interested people to sit down and discuss wetter a joint project is possible? Uninett is hiring for SimpleSAML development and that could be interesting too!
John
On Wed, Mar 14, 2012 at 12:13 AM, Thomas Gries mail@tgries.de wrote:
There's really two separate things that these systems can do.
The classic OAuth scenario is like this:
site A: Wikipedia user A site B: Huggle
Site B initiates a special login on site A using a shared secret; on success, site A passes back authentication tokens to site B which verify that user A allowed site B access.
Site B then uses those tokens when it accesses site A, in place of a username/password directly.
OpenID, SAML, etc seem to be more appropriate for this scenario:
site A: Wikipedia site B: University user B
These systems allow user B to verify their identity to site A; one possibility is to use this to associate a user A' with the remote user B, letting you use the remote ID verification in place of a local password authentication. (This is what our current OpenID extension does, basically.)
These are, IMO, totally separate use cases and I'm not sure they should be treated the same.
The Extension:OpenID can be used for both cases ( given, that you set $wgOpenIDClientOnly = false; ) https://www.mediawiki.org/wiki/Extension:OpenID .
"The extension makes a MediaWiki installation OpenID 2.0-aware and lets users log in using their OpenID identity - a special URL - instead of (or as an alternative to) standard username/password log in. In that way, the MediaWiki acts as Relying part (RP) = OpenID consumer.[1]
*As an option, it also allows the*_*MediaWiki to act as OpenID provider*, _so that users with an account on that wiki can use their userpage URL as OpenID with which they can log in to other OpenID-aware web sites."
set $wgOpenIDClientOnly = false; if you want this
Tom.
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
Petr,
OAuth is something we're committing to on the roadmap for Summer/Fall of this year. So baring anything crazy occurring, oauth should be happening over the next few months. I'm planning to help drive the process from WMF's side, but it's something I'm hoping some people in the community will also take on and help with.
I've heard the mobile, api, and labs all want oauth to help with their projects. But can we start collecting specific user stories from anyone who wants to use oauth?
It looks like most of the wikitech conversations have made it to http://www.mediawiki.org/wiki/OAuth, but would someone be willing to make sure it's up to date? I'll try to also get to over the next few days.
Thanks!
Chris
On Fri, Apr 27, 2012 at 4:40 AM, Petr Bena benapetr@gmail.com wrote:
Some updates on this? Is WMF or someone going to work on this or it's waiting for someone to start?
On Fri, Mar 16, 2012 at 3:19 PM, Petr Bena benapetr@gmail.com wrote:
Sorry, few typos:
So, right now a question is if it's supposed to be implemented as extension or in core, or both (in case extension can't be created now, update core so that it's possible).
^ that's what I was about to say
On Fri, Mar 16, 2012 at 3:17 PM, Petr Bena benapetr@gmail.com wrote:
So, right now a question is if it's supposed to be implemented as extension or in core, or both (in case extension can't be created now, updated core do that it's possible).
I would rather make is as extension since there is a little benefit for most of mediawiki users in having this feature. I think it's better to keep only necessary stuff inside core and keep extra stuff as extensions.
Is there any objection against implementing it as extension? Thanks
On Wed, Mar 14, 2012 at 12:49 AM, John Erling Blad jeblad@gmail.com
wrote:
Just as an idea, would it be possible for Wikimedia Foundation to establish some kind of joint project with the SimpleSAMLphp-folks? Those are basically Uninett, which is FEIDE, which is those that handle identity federation for lots of the Norwegian schools, colleges and universities.. The SimpleSAML solution is in use in several other projects/countries, not sure whats the current status. The platform for FEIDE is also in use in several other countries so if the log on problems in Norway are solved other countries will be able to use the same solution.
Note also that OAuth 2.0 seems to be supported.
https://rnd.feide.no/2012/03/08/releasing-a-oauth-2-0-javascript-library/
In april this year there is a conference GoOpen 2012 (http://www.goopen.no/) in Oslo and some folks from Wikimedia Foundation is there, perhaps some folks from Uninett too? Could it be possible for interested people to sit down and discuss wetter a joint project is possible? Uninett is hiring for SimpleSAML development and that could be interesting too!
John
On Wed, Mar 14, 2012 at 12:13 AM, Thomas Gries mail@tgries.de wrote:
There's really two separate things that these systems can do.
The classic OAuth scenario is like this:
site A: Wikipedia user A site B: Huggle
Site B initiates a special login on site A using a shared secret; on success, site A passes back authentication tokens to site B which
verify
that user A allowed site B access.
Site B then uses those tokens when it accesses site A, in place of a username/password directly.
OpenID, SAML, etc seem to be more appropriate for this scenario:
site A: Wikipedia site B: University user B
These systems allow user B to verify their identity to site A; one possibility is to use this to associate a user A' with the remote
user B,
letting you use the remote ID verification in place of a local
password
authentication. (This is what our current OpenID extension does,
basically.)
These are, IMO, totally separate use cases and I'm not sure they
should be
treated the same.
The Extension:OpenID can be used for both cases ( given, that you set $wgOpenIDClientOnly = false; ) https://www.mediawiki.org/wiki/Extension:OpenID .
"The extension makes a MediaWiki installation OpenID 2.0-aware and
lets
users log in using their OpenID identity - a special URL - instead of (or as an alternative to) standard username/password log in. In that way, the MediaWiki acts as Relying part (RP) = OpenID consumer.[1]
*As an option, it also allows the*_*MediaWiki to act as OpenID provider*, _so that users with an account on that wiki can use their userpage URL as OpenID with which they can log in to other
OpenID-aware
web sites."
set $wgOpenIDClientOnly = false; if you want this
Tom.
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
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
The current version of http://www.mediawiki.org/wiki/OAuth was written by me and Dario. It's definitely a starting point and not a finished proposal. I am not sure to what extent the OAuth 2 protocol has evolved since this was written but that definitely needs to be checked.
Diederik
On Fri, Apr 27, 2012 at 1:52 PM, Chris Steipp csteipp@wikimedia.org wrote:
Petr,
OAuth is something we're committing to on the roadmap for Summer/Fall of this year. So baring anything crazy occurring, oauth should be happening over the next few months. I'm planning to help drive the process from WMF's side, but it's something I'm hoping some people in the community will also take on and help with.
I've heard the mobile, api, and labs all want oauth to help with their projects. But can we start collecting specific user stories from anyone who wants to use oauth?
It looks like most of the wikitech conversations have made it to http://www.mediawiki.org/wiki/OAuth, but would someone be willing to make sure it's up to date? I'll try to also get to over the next few days.
Thanks!
Chris
On Fri, Apr 27, 2012 at 4:40 AM, Petr Bena benapetr@gmail.com wrote:
Some updates on this? Is WMF or someone going to work on this or it's waiting for someone to start?
On Fri, Mar 16, 2012 at 3:19 PM, Petr Bena benapetr@gmail.com wrote:
Sorry, few typos:
So, right now a question is if it's supposed to be implemented as extension or in core, or both (in case extension can't be created now, update core so that it's possible).
^ that's what I was about to say
On Fri, Mar 16, 2012 at 3:17 PM, Petr Bena benapetr@gmail.com wrote:
So, right now a question is if it's supposed to be implemented as extension or in core, or both (in case extension can't be created now, updated core do that it's possible).
I would rather make is as extension since there is a little benefit for most of mediawiki users in having this feature. I think it's better to keep only necessary stuff inside core and keep extra stuff as extensions.
Is there any objection against implementing it as extension? Thanks
On Wed, Mar 14, 2012 at 12:49 AM, John Erling Blad jeblad@gmail.com
wrote:
Just as an idea, would it be possible for Wikimedia Foundation to establish some kind of joint project with the SimpleSAMLphp-folks? Those are basically Uninett, which is FEIDE, which is those that handle identity federation for lots of the Norwegian schools,
colleges
and universities.. The SimpleSAML solution is in use in several other projects/countries, not sure whats the current status. The platform for FEIDE is also in use in several other countries so if the log on problems in Norway are solved other countries will be able to use the same solution.
Note also that OAuth 2.0 seems to be supported.
https://rnd.feide.no/2012/03/08/releasing-a-oauth-2-0-javascript-library/
In april this year there is a conference GoOpen 2012 (http://www.goopen.no/) in Oslo and some folks from Wikimedia Foundation is there, perhaps some folks from Uninett too? Could it be possible for interested people to sit down and discuss wetter a joint project is possible? Uninett is hiring for SimpleSAML development and that could be interesting too!
John
On Wed, Mar 14, 2012 at 12:13 AM, Thomas Gries mail@tgries.de
wrote:
There's really two separate things that these systems can do.
The classic OAuth scenario is like this:
site A: Wikipedia user A site B: Huggle
Site B initiates a special login on site A using a shared secret; on success, site A passes back authentication tokens to site B which
verify
that user A allowed site B access.
Site B then uses those tokens when it accesses site A, in place of a username/password directly.
OpenID, SAML, etc seem to be more appropriate for this scenario:
site A: Wikipedia site B: University user B
These systems allow user B to verify their identity to site A; one possibility is to use this to associate a user A' with the remote
user B,
letting you use the remote ID verification in place of a local
password
authentication. (This is what our current OpenID extension does,
basically.)
These are, IMO, totally separate use cases and I'm not sure they
should be
treated the same.
The Extension:OpenID can be used for both cases ( given, that you
set
$wgOpenIDClientOnly = false; ) https://www.mediawiki.org/wiki/Extension:OpenID .
"The extension makes a MediaWiki installation OpenID 2.0-aware and
lets
users log in using their OpenID identity - a special URL - instead
of
(or as an alternative to) standard username/password log in. In that way, the MediaWiki acts as Relying part (RP) = OpenID consumer.[1]
*As an option, it also allows the*_*MediaWiki to act as OpenID provider*, _so that users with an account on that wiki can use their userpage URL as OpenID with which they can log in to other
OpenID-aware
web sites."
set $wgOpenIDClientOnly = false; if you want this
Tom.
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
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 still have the same stance on the topic as before: http://thread.gmane.org/gmane.science.linguistics.wikipedia.technical/59502
I really don't want MediaWiki to fall into the trap of implementing this in a way that ONLY works with OAuth 2, completely excludes other protocols (OAuth 1, signature based OAuth 2 if still around, something like Google 2-factor's app passwords, etc...), and doesn't include proper integration of logging what app makes what actions killing our ability to properly handle misbehaving apps.
Well, make sure to participate in the development of the system then!
On Fri, Apr 27, 2012 at 3:12 PM, Daniel Friesen lists@nadir-seen-fire.com wrote:
I still have the same stance on the topic as before: http://thread.gmane.org/gmane.science.linguistics.wikipedia.technical/59502
I really don't want MediaWiki to fall into the trap of implementing this in a way that ONLY works with OAuth 2, completely excludes other protocols (OAuth 1, signature based OAuth 2 if still around, something like Google 2-factor's app passwords, etc...), and doesn't include proper integration of logging what app makes what actions killing our ability to properly handle misbehaving apps.
-- ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
On Fri, 27 Apr 2012 10:52:33 -0700, Chris Steipp csteipp@wikimedia.org wrote:
Petr,
OAuth is something we're committing to on the roadmap for Summer/Fall of this year. So baring anything crazy occurring, oauth should be happening over the next few months. I'm planning to help drive the process from WMF's side, but it's something I'm hoping some people in the community will also take on and help with.
I've heard the mobile, api, and labs all want oauth to help with their projects. But can we start collecting specific user stories from anyone who wants to use oauth?
It looks like most of the wikitech conversations have made it to http://www.mediawiki.org/wiki/OAuth, but would someone be willing to make sure it's up to date? I'll try to also get to over the next few days.
Thanks!
Chris
On Fri, Apr 27, 2012 at 4:40 AM, Petr Bena benapetr@gmail.com wrote:
Some updates on this? Is WMF or someone going to work on this or it's waiting for someone to start?
On Fri, Mar 16, 2012 at 3:19 PM, Petr Bena benapetr@gmail.com wrote:
Sorry, few typos:
So, right now a question is if it's supposed to be implemented as extension or in core, or both (in case extension can't be created now, update core so that it's possible).
^ that's what I was about to say
On Fri, Mar 16, 2012 at 3:17 PM, Petr Bena benapetr@gmail.com wrote:
So, right now a question is if it's supposed to be implemented as extension or in core, or both (in case extension can't be created now, updated core do that it's possible).
I would rather make is as extension since there is a little benefit for most of mediawiki users in having this feature. I think it's better to keep only necessary stuff inside core and keep extra stuff as extensions.
Is there any objection against implementing it as extension? Thanks
On Wed, Mar 14, 2012 at 12:49 AM, John Erling Blad jeblad@gmail.com
wrote:
Just as an idea, would it be possible for Wikimedia Foundation to establish some kind of joint project with the SimpleSAMLphp-folks? Those are basically Uninett, which is FEIDE, which is those that handle identity federation for lots of the Norwegian schools, colleges and universities.. The SimpleSAML solution is in use in several other projects/countries, not sure whats the current status. The platform for FEIDE is also in use in several other countries so if the log on problems in Norway are solved other countries will be able to use the same solution.
Note also that OAuth 2.0 seems to be supported.
https://rnd.feide.no/2012/03/08/releasing-a-oauth-2-0-javascript-library/
In april this year there is a conference GoOpen 2012 (http://www.goopen.no/) in Oslo and some folks from Wikimedia Foundation is there, perhaps some folks from Uninett too? Could it be possible for interested people to sit down and discuss wetter a joint project is possible? Uninett is hiring for SimpleSAML development and that could be interesting too!
John
On Wed, Mar 14, 2012 at 12:13 AM, Thomas Gries mail@tgries.de wrote: > > > There's really two separate things that these systems can do. > > The classic OAuth scenario is like this: > > site A: Wikipedia > user A > site B: Huggle > > Site B initiates a special login on site A using a shared secret; on > success, site A passes back authentication tokens to site B which
verify
> that user A allowed site B access. > > Site B then uses those tokens when it accesses site A, in place of a > username/password directly. > > > OpenID, SAML, etc seem to be more appropriate for this scenario: > > site A: Wikipedia > site B: University > user B > > These systems allow user B to verify their identity to site A; one > possibility is to use this to associate a user A' with the remote
user B,
> letting you use the remote ID verification in place of a local
password
> authentication. (This is what our current OpenID extension does,
basically.)
> > > These are, IMO, totally separate use cases and I'm not sure they
should be
> treated the same. > > > The Extension:OpenID can be used for both cases ( given, that you > set > $wgOpenIDClientOnly = false; ) > https://www.mediawiki.org/wiki/Extension:OpenID . > > "The extension makes a MediaWiki installation OpenID 2.0-aware and
lets
> users log in using their OpenID identity - a special URL - instead > of > (or as an alternative to) standard username/password log in. In that > way, the MediaWiki acts as Relying part (RP) = OpenID consumer.[1] > > *As an option, it also allows the*_*MediaWiki to act as OpenID > provider*, _so that users with an account on that wiki can use their > userpage URL as OpenID with which they can log in to other
OpenID-aware
> web sites." > > set > $wgOpenIDClientOnly = false; > if you want this > > Tom.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Am 28.04.2012 00:18, schrieb Ryan Lane:
Well, make sure to participate in the development of the system then!
On Fri, Apr 27, 2012 at 3:12 PM, Daniel Friesen lists@nadir-seen-fire.com wrote:
I still have the same stance on the topic as before:
sorry to drop in, just a question: why haven't you ever thought about implementing Extension:OpenID ? Tom
Am 28.04.2012 00:25, schrieb Ryan Lane:
sorry to drop in, just a question: why haven't you ever thought about implementing Extension:OpenID ?
Well, this discussion is on OAuth. They do different things.
- Ryan
okay : http://stackoverflow.com/questions/1087031/whats-the-difference-between-open...
Good, concise answer Tom.
If you have an OAuth use case / user story, please update: http://www.mediawiki.org/wiki/OAuth/User_stories
Thanks!
On Fri, Apr 27, 2012 at 3:29 PM, Thomas Gries mail@tgries.de wrote:
Am 28.04.2012 00:25, schrieb Ryan Lane:
sorry to drop in, just a question: why haven't you ever thought about implementing Extension:OpenID ?
Well, this discussion is on OAuth. They do different things.
- Ryan
okay :
http://stackoverflow.com/questions/1087031/whats-the-difference-between-open...
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Fri, Apr 27, 2012 at 4:05 PM, Chris Steipp csteipp@wikimedia.org wrote:
If you have an OAuth use case / user story, please update: http://www.mediawiki.org/wiki/OAuth/User_stories
Hi everyone,
I'd like to second this ^^^ Support for OAuth is not a binary thing, and so we'll need these user stories to start in earnest on this.
Here's how I see the process of building this feature working. Chris is available to lead all of this, but if someone wants to volunteer to do any of this, we don't want to get in the way: Phase 1: User story gathering. User stories seem to be the most sensible way of doing requirements gathering in a collaborative way, since it's easier to prioritize a big list of user stories than it is to prioritize abstract requirements.
Phase 2: User story prioritization and requirements distillation. Once the user stories stop trickling in, then we can do rough prioritization on the stories (high, medium, low). This is going to be guided by a combination of community input and technical feasibility. We'll need to distill the requirements from the user stories to find common functionality between various stories.
Phase 3: Making the backlog - we'll then construct the initial backlog based on some number of the higher priority user stories.
Phase 4: Implementation - start chipping away at the backlog
We have some smaller security projects that we'd like Chris to code on before starting in on this, so it'll be a while before Chris starts in on phase 4. However, he's available to start this process now, so if there's an experienced volunteer developer that can pair with Chris now, we could make this happen a lot faster.
Any takers?
Rob
I don't have much experiences in this area, but I really want to see this happen, so if there is anything I can help with (for example set up a test site on wikimedia labs where we could work on this), let me know. As soon as there is any public code I can take a look in that and try to participate on development as well, if I could
On Sat, Apr 28, 2012 at 2:48 AM, Rob Lanphier robla@wikimedia.org wrote:
On Fri, Apr 27, 2012 at 4:05 PM, Chris Steipp csteipp@wikimedia.org wrote:
If you have an OAuth use case / user story, please update: http://www.mediawiki.org/wiki/OAuth/User_stories
Hi everyone,
I'd like to second this ^^^ Support for OAuth is not a binary thing, and so we'll need these user stories to start in earnest on this.
Here's how I see the process of building this feature working. Chris is available to lead all of this, but if someone wants to volunteer to do any of this, we don't want to get in the way: Phase 1: User story gathering. User stories seem to be the most sensible way of doing requirements gathering in a collaborative way, since it's easier to prioritize a big list of user stories than it is to prioritize abstract requirements.
Phase 2: User story prioritization and requirements distillation. Once the user stories stop trickling in, then we can do rough prioritization on the stories (high, medium, low). This is going to be guided by a combination of community input and technical feasibility. We'll need to distill the requirements from the user stories to find common functionality between various stories.
Phase 3: Making the backlog - we'll then construct the initial backlog based on some number of the higher priority user stories.
Phase 4: Implementation - start chipping away at the backlog
We have some smaller security projects that we'd like Chris to code on before starting in on this, so it'll be a while before Chris starts in on phase 4. However, he's available to start this process now, so if there's an experienced volunteer developer that can pair with Chris now, we could make this happen a lot faster.
Any takers?
Rob
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Tue, 13 Mar 2012 04:50:05 -0800, Petr Bena benapetr@gmail.com wrote:
Hi, it's been almost 4 years since we came with the idea of implementing an OAuth to mediawiki. I think it's time to start. Question now is if it should be a part of core or extension for mediawiki. I myself would rather make it as extension, since there is probably no use for most of installations, except for large wikis.
Quote: OAuth provides a standard protocol to negotiate secure access tokens and to provide third-party tools (web or client) with granular access to private resources. This protocol does not reveal usernames or passwords to the third-party tool. Offering OAuth based authorization on Mediawiki wiki's will increase the reusability of its data and spur the creation of an ecosystem of app's around Mediawiki.
Is there anyone who is willing to help with this? If there is no one interested in this, or no comments, I would start a new extension called OAuth, which only purpose would be to enable this feature in mediawiki.
- We should support more than 'just' OAuth. There are reasons one might want OAuth 1, others might want OAuth 2, someone may come up with a better OAuth 3, or we may come up with a custom auth setup such as Google's application passwords for sites with no ssl. - We need generic code for handling the grouping of permissions that are handed out to applications. - Generic code for revoking applications and specifying new applications. - We need revisions, logs, etc... to all be able to be annotated with information about what application made the change. - We need tools that will allow administrators to block applications and easily and quickly revert large batches of changes made by an application that has gone rogue.
Hence OAuth should really be implemented as a combination of core code an extension.
The code that annotates revisions, etc... should be implemented in core. Along with permissions grouping. The UI for specifying, revoking, blocking, etc... applications. Perhaps an abstract UI for the visuals of what an "Allow" / "Deny" page will look like. Core would then be given a pluggable interface for protocols that allow for authorization of users.
An OAuth1 or OAuth2 extension would then be implemented that implements OAuth using that pluggable interface so that OAuth becomes an option for applications.
wikitech-l@lists.wikimedia.org