[Mailman-Developers] Architecture for extra profile info
Richard Wackerbarth
rkw at dataplex.net
Sat Apr 27 13:27:55 CEST 2013
I think that we are advocating the same approach.
Your example is better tailored to actual MM resources and can be substituted for the one that I referenced.
Note: I am "speaking" conceptually. The actual hard design of the details would be the scope of work for a GSoC project.
The easiest way to present all of the details is to actually create a reference implementation. :)
On Apr 27, 2013, at 3:21 AM, Xu Wang <xuwang at gmail.com> wrote:
> 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 at 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 at 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 at 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_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 <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
More information about the Mailman-Developers
mailing list