Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Wikipedia: Wikitech

OAuth

 

 

First page Previous page 1 2 Next page Last page  View All Wikipedia wikitech RSS feed   Index | Next | Previous | View Threaded


benapetr at gmail

Mar 13, 2012, 5:50 AM

Post #1 of 41 (1227 views)
Permalink
OAuth

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 [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


martijnhoekstra at gmail

Mar 13, 2012, 6:39 AM

Post #2 of 41 (1211 views)
Permalink
Re: OAuth [In reply to]

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 [at] gmail> 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 [at] lists
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


compwhizii at gmail

Mar 13, 2012, 7:09 AM

Post #3 of 41 (1208 views)
Permalink
Re: OAuth [In reply to]

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 [at] gmail> 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 [at] lists
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l



--
John

_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


benapetr at gmail

Mar 13, 2012, 7:13 AM

Post #4 of 41 (1217 views)
Permalink
Re: OAuth [In reply to]

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 [at] gmail> 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 [at] gmail> 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 [at] lists
>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
>
>
> --
> John
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l [at] lists
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


benapetr at gmail

Mar 13, 2012, 7:17 AM

Post #5 of 41 (1210 views)
Permalink
Re: OAuth [In reply to]

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 [at] gmail> 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 [at] gmail> 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 [at] gmail> 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 [at] lists
>>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>>
>>
>>
>> --
>> John
>>
>> _______________________________________________
>> Wikitech-l mailing list
>> Wikitech-l [at] lists
>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


jeff at storyinmemo

Mar 13, 2012, 7:18 AM

Post #6 of 41 (1208 views)
Permalink
Re: OAuth [In reply to]

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 [at] lists
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l


_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


jeblad at gmail

Mar 13, 2012, 8:10 AM

Post #7 of 41 (1216 views)
Permalink
Re: OAuth [In reply to]

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 [at] storyinmemo> 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 [at] lists
>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l [at] lists
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


benapetr at gmail

Mar 13, 2012, 8:21 AM

Post #8 of 41 (1216 views)
Permalink
Re: OAuth [In reply to]

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 [at] gmail> 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 [at] storyinmemo> 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 [at] lists
>>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>>
>>
>> _______________________________________________
>> Wikitech-l mailing list
>> Wikitech-l [at] lists
>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l [at] lists
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


mail at tgries

Mar 13, 2012, 11:37 AM

Post #9 of 41 (1209 views)
Permalink
Re: OAuth [In reply to]

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.
Attachments: signature.asc (0.48 KB)


lists at nadir-seen-fire

Mar 13, 2012, 12:21 PM

Post #10 of 41 (1210 views)
Permalink
Re: OAuth [In reply to]

On Tue, 13 Mar 2012 04:50:05 -0800, Petr Bena <benapetr [at] gmail> 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.


--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]

_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


rlane32 at gmail

Mar 13, 2012, 3:14 PM

Post #11 of 41 (1219 views)
Permalink
Re: OAuth [In reply to]

On Tue, Mar 13, 2012 at 8:10 AM, John Erling Blad <jeblad [at] gmail> 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:

http://simplesamlphp.org/

It supports SAML, OpenID, OAuth, it's extendable and it supports
multiple backends (LDAP, MySQL, etc). It is also localizable.

- Ryan

_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


jeblad at gmail

Mar 13, 2012, 3:32 PM

Post #12 of 41 (1206 views)
Permalink
Re: OAuth [In reply to]

> So, since we're discussing SAML and OAuth and OpenID, and such, I
> should mention this:
>
>    http://simplesamlphp.org/
>
> 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

_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


brion at pobox

Mar 13, 2012, 4:04 PM

Post #13 of 41 (1207 views)
Permalink
Re: OAuth [In reply to]

On Tue, Mar 13, 2012 at 3:32 PM, John Erling Blad <jeblad [at] gmail> wrote:

> > So, since we're discussing SAML and OAuth and OpenID, and such, I
> > should mention this:
> >
> > http://simplesamlphp.org/
> >
> > 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
_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


mail at tgries

Mar 13, 2012, 4:13 PM

Post #14 of 41 (1209 views)
Permalink
Re: OAuth [In reply to]

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.
Attachments: signature.asc (0.48 KB)


jeblad at gmail

Mar 13, 2012, 4:49 PM

Post #15 of 41 (1211 views)
Permalink
Re: OAuth [In reply to]

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 [at] tgries> 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 [at] lists
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


benapetr at gmail

Mar 16, 2012, 7:17 AM

Post #16 of 41 (1197 views)
Permalink
Re: OAuth [In reply to]

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 [at] gmail> 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 [at] tgries> 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 [at] lists
>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l [at] lists
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


benapetr at gmail

Mar 16, 2012, 7:19 AM

Post #17 of 41 (1199 views)
Permalink
Re: OAuth [In reply to]

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 [at] gmail> 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 [at] gmail> 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 [at] tgries> 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 [at] lists
>>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>>
>> _______________________________________________
>> Wikitech-l mailing list
>> Wikitech-l [at] lists
>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


benapetr at gmail

Apr 27, 2012, 4:40 AM

Post #18 of 41 (1128 views)
Permalink
Re: OAuth [In reply to]

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 [at] gmail> 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 [at] gmail> 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 [at] gmail> 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 [at] tgries> 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 [at] lists
>>>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>>>
>>> _______________________________________________
>>> Wikitech-l mailing list
>>> Wikitech-l [at] lists
>>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


csteipp at wikimedia

Apr 27, 2012, 10:52 AM

Post #19 of 41 (1127 views)
Permalink
Re: OAuth [In reply to]

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 [at] gmail> 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 [at] gmail> 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 [at] gmail> 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 [at] gmail>
> 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 [at] tgries> 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 [at] lists
> >>>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> >>>
> >>> _______________________________________________
> >>> Wikitech-l mailing list
> >>> Wikitech-l [at] lists
> >>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l [at] lists
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


dvanliere at gmail

Apr 27, 2012, 11:23 AM

Post #20 of 41 (1129 views)
Permalink
Re: OAuth [In reply to]

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 [at] wikimedia> 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 [at] gmail> 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 [at] gmail> 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 [at] gmail> 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 [at] gmail>
> > 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 [at] tgries>
> 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 [at] lists
> > >>>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> > >>>
> > >>> _______________________________________________
> > >>> Wikitech-l mailing list
> > >>> Wikitech-l [at] lists
> > >>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> >
> > _______________________________________________
> > Wikitech-l mailing list
> > Wikitech-l [at] lists
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> >
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l [at] lists
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


lists at nadir-seen-fire

Apr 27, 2012, 3:12 PM

Post #21 of 41 (1129 views)
Permalink
Re: OAuth [In reply to]

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 [at] wikimedia>
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 [at] gmail> 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 [at] gmail> 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 [at] gmail> 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 [at] gmail>
>> 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 [at] tgries>
>> 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 [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


rlane32 at gmail

Apr 27, 2012, 3:18 PM

Post #22 of 41 (1128 views)
Permalink
Re: OAuth [In reply to]

Well, make sure to participate in the development of the system then!

On Fri, Apr 27, 2012 at 3:12 PM, Daniel Friesen
<lists [at] nadir-seen-fire> 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 [at] wikimedia>
> 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 [at] gmail> 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 [at] gmail> 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 [at] gmail> 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 [at] gmail>
>>> 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 [at] tgries>
>>> >>> 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 [at] lists
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


mail at tgries

Apr 27, 2012, 3:21 PM

Post #23 of 41 (1127 views)
Permalink
Re: OAuth [In reply to]

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 [at] nadir-seen-fire> 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



_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


rlane32 at gmail

Apr 27, 2012, 3:25 PM

Post #24 of 41 (1130 views)
Permalink
Re: OAuth [In reply to]

> 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

_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


mail at tgries

Apr 27, 2012, 3:29 PM

Post #25 of 41 (1128 views)
Permalink
Re: OAuth [In reply to]

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-openid-and-oauth


_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

First page Previous page 1 2 Next page Last page  View All Wikipedia wikitech RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.