Here is my take on the basic system requirements and design issues: System Components: * A RESTful API<https://en.wikipedia.org/wiki/Representational_state_transfer#RESTful_web_APIs> - a mini-server that servers restful calls. * A persistent store - a schemaless or relaxed datasource, e.g. Mongodb * An authn/authz service to support api authn/authz and account management options for authn: - no auth, open to localhost, off load the AC to clients. - base auth<http://en.wikipedia.org/wiki/Basic_access_authentication>, username/pwd, requires https and minimum client effort. - HMAC auth<http://en.wikipedia.org/wiki/Hash-based_message_authentication_code>, requires clients to sign the requests with shared secrets, e.g. oauth1 and AWS S3 auth. Needs out-of-band secretes and token management and distribution. options for authz (privileges are http methods combined with endpoint/scope): - role based, i.e. privileges are associated with role, work with base auth. - owner based, i.e. privileges are associated with user, work with base auth. - token based, i.e. privileges are associated with token, see OAuth <http://en.wikipedia.org/wiki/OAuth> and HMAC auth<http://en.wikipedia.org/wiki/Hash-based_message_authentication_code>
Resource/Data model servered by API: * TBD, means data model changes "as-we-go". A few initial data type should be given as a start point, or as examples: - users - mailing_lists - subscriptions - user_profiles - accounts etc. * data presentation should be HATEOAS<http://en.wikipedia.org/wiki/HATEOAS> enabled. * content-type, applicaion/json, xml, html, etc. * etag should be used to support caching control and concurrency control. * each resource servered by the api may have a simple validation schema, i.e. in some sort of DSL. Implementation Consideration: * Small footprint. * The API mechanism should decoupled with the resource data model to allow maximum flexibility. * Due to the decoupling of API and the resource data model, the API may only have limited support for advanced or customized quires. * It is a "garbage-in, garbage-out" service, i.e. no or minmum data manipulation by the service. E.g. if you post in a clear texted password with user's data, it will stay clear in the database, and return back as plain text when someone gets. * Service oriented, i.e runs as an independent first-class service. * DRY, use other good open source packages whenever possible. * In Python :-) Relations to other system components: * Open... and RESTful 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/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9