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 <xuw...@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 > <step...@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@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@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 _______________________________________________ Mailman-Developers mailing list Mailman-Developers@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/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
