Here is an example of what it might look like for "user" resource returned by the api (without any auth):

curl http://localhost:5000/api/v1/users/517b5560f84a4b13d239fc59/ HTTP/1.0 200 OK Content-Type: application/json Content-Length: 1232 Cache-Control: max-age=20,must-revalidate Expires: Sat, 27 Apr 2013 08:07:04 GMT ETag: 8252e88a72eea8fd4c93aa57435a3857f618d5d1 Last-Modified: Sat, 27 Apr 2013 04:34:40 UTC Date: Sat, 27 Apr 2013 08:03:44 GMT

{ "_id": "517b5560f84a4b13d239fc59", "_links": { "collection": { "href": "localhost:5000/api/v1/users/", "title": "users" }, "parent": { "href": "localhost:5000/api/v1", "title": "home" }, "self": { "href": "localhost:5000/api/v1/users/517b5560f84a4b13d239fc59/", "title": "user" } }, "created": "Sat, 27 Apr 2013 04:34:40 UTC", "email": "swesgymt@baqlwrzxqfjpofpy.nl", "firstname": "wtegrglnub", "lastname": "bjsbvjrn", "roles": "level_3", "subscriptions": [ { "href": "localhost:5000/api/v1/mlists/517b5560f84a4b13d239fc56/", "options": { "option_0": "qifqk", "option_1": "qyqyx", "option_2": "dirkf", "option_3": "yjrtv", "option_4": "mljew" }, "ref": "517b5560f84a4b13d239fc56", "title": "mailing list" }, { "href": "localhost:5000/api/v1/mlists/517b5560f84a4b13d239fc58/", "options": { "option_0": "aixqy", "option_1": "triwy", "option_2": "aponq", "option_3": "xmorj", "option_4": "szmig" }, "ref": "517b5560f84a4b13d239fc58", "title": "mailing list" }, { "href": "localhost:5000/api/v1/mlists/517b5560f84a4b13d239fc54/", "options": { "option_0": "ltops", "option_1": "bojfl", "option_2": "qjsyl", "option_3": "ndtof", "option_4": "diass" }, "ref": "517b5560f84a4b13d239fc54", "title": "mailing list" } ], "updated": "Sat, 27 Apr 2013 04:34:40 UTC" }

and let's follow the last of mailing list link in the users.subscriptions:

$ curl -i 'localhost:5000/api/v1/mlists/517b5560f84a4b13d239fc54/'

HTTP/1.0 200 OK Content-Type: application/json Content-Length: 711 Cache-Control: max-age=20,must-revalidate Expires: Sat, 27 Apr 2013 08:05:00 GMT ETag: eea6cfa4fc6311a1ea3c5c4189597ab962369d34 Last-Modified: Sat, 27 Apr 2013 04:34:40 UTC Date: Sat, 27 Apr 2013 08:04:40 GMT

{ "_id": "517b5560f84a4b13d239fc54", "_links": { "collection": { "href": "localhost:5000/api/v1/mlists/", "title": "mlists" }, "parent": { "href": "localhost:5000/api/v1", "title": "home" }, "self": { "href": "localhost:5000/api/v1/mlists/517b5560f84a4b13d239fc54/", "title": "mailing list" } }, "address": "auxriarr@rdrfzfmvluylkegy.ca", "created": "Sat, 27 Apr 2013 04:34:40 UTC", "description": "krtejcbwmedzftdvjwagmbqkkiajubnzezxstahexvkrjncecdwsyfjlbobgjuxevwgflxlnemqtqcjz", "option": { "option_0": "vwmum" }, "owners": [ { "href": "localhost:5000/api/v1/users/517b5560f84a4b13d239fc59/", "name": "wtegrglnub bjsbvjrn", "ref": "517b5560f84a4b13d239fc59", "title": "user" } ], "updated": "Sat, 27 Apr 2013 04:34:40 UTC" }

On Sat, Apr 27, 2013 at 1:00 AM, Xu Wang <xuwang@gmail.com> wrote:

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_AP...> - 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 <stephen@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