[Mailman-Developers] Architecture for extra profile info

[Xu Wang]

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
>