[Mailman-Developers] Architecture for extra profile info

[Richard Wackerbarth]

I, and I think Stephen, are advocating the use of oAuth as a "login" method. Just as BrowserID provides a third party identifier, Google, Twitter, Facebook, etc. provide similar service through oAuth protocols. MM should be configurable to accept those, or other enterprise-provided identifiers.

On Apr 27, 2013, at 2:42 AM, Xu Wang <xuwang at gmail.com> wrote:

> For OAuth <http://en.wikipedia.org/wiki/OAuth>, you need to implement token
> based auth in API, as well as a provider service because there is no open
> OAuth provider service for third party API out there :-(
> 
> The provider service has to implement  application registration, user auth,
> token validation and distribution (for oauth 1a, access token need to be
> pushed to or shared with API).
> 
> In my view, OAuth really belongs to an enterprise system, rather than a
> specific api or one application. It requires a existing robust web-based
> auth system on the provider's site.
> 
> This will also make the API less "independent" because it is depending on
> the provider service and provider's auth system.
> 
> With that said, the API could have a plugin that support  "token-based"
> authorization, with an out-of-band token distribution/validation and
> management service, whatever it would be.
> 
> Only if there is a strong 3-legged auth use case, should one push to this
> controversy route.
> 
> Xu Wang
> 
> 
> On Fri, Apr 26, 2013 at 11:53 PM, Stephen J. Turnbull <stephen at xemacs.org>wrote:
> 
>> Abhilash Raj writes:
>> 
>>> Hi all,
>>> I wrote a brief summary[1] of this thread.
>> 
>> You've misinterpreted or mistyped a couple things I wrote:
>> 
>> I'm not against OAuth in general, just against Mailman being an OAuth
>> *provider*, or bundling one, because we can't support it properly.
>> Users should get auth stuff from somebody whose primary interest is
>> security stuff.
>> 
>> When I write authentication and authorization should be avoided, I
>> don't mean Mailman doesn't authenticate and authorize users.  I mean
>> the implementation should be delegated to robust, well-tested modules
>> or external applications (eg, Apache) whereever possible.
>> 
>> The last quote needs to be fleshed out.  "This practice" refers to not
>> exposing keys and other secrets to the whole application, including
>> cooperating processes.  If authentication can be done in one place and
>> an internal session or one-time authorization be granted, that's what
>> should be done, rather than exposing user credentials to other parts
>> of the application to do their own authentication and authorization.
>> 
>> In making such a summary, I think it would be better to organize by
>> topic.  Eg, a partial outline:
>> 
>> REST API for extended user profiles
>>  Authorization
>>    Trusting local connections
>>    HTTP Basic
>>    OAuth
>>    - Recommended for "outside world" [Florian]
>>    - Advocates including an OAuth provider as a non-default,
>>      experts-only option [Florian]
>>    - Opposes bundling an OAuth provider [Stephen]
>>    - OAuth necessary?  Why isn't HTTPS + Basic Auth good enough for
>>      now? [Stephen]
>>    - Don't need an OAuth provider to share authorizations (in fact,
>>      at least in OAuth 2.0, providers don't provide sharing at all)
>>      [Stephen]
>>    - Implementing OAuth provider doesn't provide the benefits of
>>      OAuth (ie, add an OAuth provider means users have yet another
>>      set of credentials to manage) [Stephen]
>>    - OAuth architecture = provider + client + consumer [Richard]
>>    - Agrees to Mailman as OAuth consumer, not provider [Richard]
>>    - OAuth may be overengineering, at first [Barry]
>>  Database schemas
>>  Database implementations
>>  Wire Protocol
>> etc...
>> 
>> Also, in that format it's easy to reorganize:
>> 
>> REST API for extended user profiles
>>  Authorization
>>    Trusting local connections
>>    HTTP Basic
>>    OAuth
>>    - OAuth architecture = provider + client + consumer [Richard]
>>    - Use client in Mailman?
>>      - Recommended for "outside world" [Florian]
>>      - Agrees to Mailman as OAuth consumer, not provider [Richard]
>>      - OAuth necessary?  Why isn't HTTPS + Basic Auth good enough for
>>        now? [Stephen]
>>      - OAuth may be overengineering, at first [Barry]
>>    - Use provider in Mailman?
>>      - Advocates including an OAuth provider as a non-default,
>>        experts-only option [Florian]
>>      - Opposes bundling an OAuth provider [Stephen, Richard]
>>      - Implementing OAuth provider doesn't provide the benefits of
>>        OAuth (ie, add an OAuth provider means users have yet another
>>        set of credentials to manage) [Stephen]
>>      - Don't need an OAuth provider to share authorizations (in fact,
>>        at least in OAuth 2.0, providers don't provide sharing at all)
>>        [Stephen]
>>  Database schemas
>>  Database implementations
>>  Wire Protocol
>> etc...
>> 
>> By the way, don't go out of your way to reorganize what you've already
>> done, except as it's useful to you.  Gradually improve it as it helps
>> you to recall discussion.
>> _______________________________________________
>> Mailman-Developers mailing list
>> Mailman-Developers at python.org
>> http://mail.python.org/mailman/listinfo/mailman-developers
>> Mailman FAQ: http://wiki.list.org/x/AgA3
>> Searchable Archives:
>> http://www.mail-archive.com/mailman-developers%40python.org/
>> Unsubscribe:
>> http://mail.python.org/mailman/options/mailman-developers/xuwang%40gmail.com
>> 
>> Security Policy: http://wiki.list.org/x/QIA9
>> 
> _______________________________________________
> Mailman-Developers mailing list
> Mailman-Developers at python.org
> http://mail.python.org/mailman/listinfo/mailman-developers
> Mailman FAQ: http://wiki.list.org/x/AgA3
> Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/
> Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/rkw%40dataplex.net
> 
> Security Policy: http://wiki.list.org/x/QIA9