Mailman 3 April 2013 - Mailman-Developers

Re: [Mailman-Developers] Architecture for extra profile info
by Xu Wang 28 Apr '13

28 Apr '13

On Sun, Apr 28, 2013 at 11:27 AM, Stephen J. Turnbull <stephen(a)xemacs.org>wrote: > Xu Wang writes: > > On Sun, Apr 28, 2013 at 12:15 AM, Stephen J. Turnbull < > stephen(a)xemacs.org> > > wrote: > > > Xu Wang writes: > > > > > > > The problem is how do you "confirm ownership of the subscribed > > > > address" when a request coming with an access token. > > > > > > You don't. That was done when the OAuth ID was linked to the address, > > > using the usual 3-step handshake (submit the association, receive an > > > email containing a secret, confirm ownership by replying with the > secret). > > > > I'm not sure what you mean by "OAuth ID". > > In the case of Mailman's use cases, it will typically be an email > address at Gmail, Yahoo, or Launchpad, or some other well-known OpenID > provider. Often, but not necessarily, it will be the subscribed address. > > OpenID is about authentication. OAuth is about authorisation. What are we talking about here? Support to OpenID or support to OAuth or both? > As a resource server, the API need to validate the access token but > > how to validate the access token is not part of OAuth. > > This is some of the excess complexity (if you prefer, "enterprise > readiness") in OAuth 2.0. In Mailman usage, the resource that the > consumer gets access to will be a user ID. Eg, I might be "user: > stephen; name: Stephen Turnbull; email: stephen(a)xemacs.org; > email:stephen.turnbull.fw@u.tsukuba.ac.jp; owner: > fs-phil(a)turnbull.sk.tsukuba.ac.jp; owner: xemacs-beta(a)xemacs.org ...; > OpenID: stephenjturnbull(a)gmail.com". So when I login via OpenID > (which uses the OAuth v1 protocol AFAIK), No OpenID does not uses OAuth protocol. > the provider (GMail) asks me > to verify who I am by presenting my credential (most users will think > of this as "getting the login screen"), and in turn it testifies to > the client that I own that email at GMail, and the consumer (eg, the > HyperKitty app) then looks it up, identifies me, logs me in as > "stephen", and gives me a cookie (session auth token). The > authentication *is* the validation here. > Mailman can't use GMail as OAuth provider to protect mailman's own resource as a general authorization solution. OAuth v2 envisions more complex scenarios where the client may present > the same token repeatedly, or consumers might hang on to them and > present them to the resource owner repeatedly, or even pass them on to > other consumers. In those cases, yes, there will need to be > validation etc going on. For example, the token might be a (ID, URI, > expiration-date) tuple encrypted with the resource owner's private > key. Being able to decrypt and getting a syntactically correct, > unexpired tuple would then be validation of an authorization to fetch > that URI. (In this particular case I'm thinking of "any valid user is > OK".) This does require prior coordination between the provider and > the resource owner on token format and exchange of keys. > > But AFAICS Mailman's currently envisioned applications don't require > this complexity. > As you put it, mailman don't have to support OAuth, but if it dose, it's better stick to the protocol. > Do you have any ideas for Mailman that might require something more > fine-grained than just "this user is logged in"? > I'm new to mailman and have a very limited knowledge about what kind of "fine-grained" authorization it may need other than authentication. (read: Xu had no clue ...) >From the api implementation point of view, a role base authorization can be bundled in, which allows admin or resource owner to associate user with roles and roles with endpoints/methods.

1 0

Re: [Mailman-Developers] Architecture for extra profile info
by Stephen J. Turnbull 28 Apr '13

28 Apr '13

Xu Wang writes: > The problem is how do you "confirm ownership of the subscribed address" > when a request coming with an access token. You don't. That was done when the OAuth ID was linked to the address, using the usual 3-step handshake (submit the association, receive an email containing a secret, confirm ownership by replying with the secret). > In another words, unless your are the provider, how do you validate > the access token issued by a provider at the resource endpoint? I'm not sure what you mean. In the security context (as others), "validate" means mostly "check the syntax". But a valid token is assumed to be authentic (otherwise the provided has been suborned). Remember, a provider does not *authorize* anything. A provider offers a channel of communication to the resource owner, who does the authorization. Ie, provider tells owner "client tells me consumer wants to access the X Files", and on success returns a token to the client indicating "I've confirmed that you are indeed talking to the owner, and by the way, *she* says it's OK to let consumer look at them." > > Why? The whole point of the OAuth protocol is that the authentication > > is delegated to an OAuth client, which contacts the provider, and if > > successful returns a token to the customer. The customer then > > interprets that token as it likes. The tokens have a specific, > > well-known form, so the authentication subsystem is completely > > independent of the application API. > > > I may misunderstood you, but OAuth doesn't specify the format or > content of the access token. It is left to the implementation of a > provider. This is true for both OAuth 1.a and OAuth 2. I'd have to look again to be 100% sure, but I'm pretty sure that what the provider returns is well-defined. What the client gives to the application is application-defined. > To control the access of a resource, a provider have to authenticate both > client and the resource owner, issue an access token if authenticated > resource owner authorized the resource access for a specific client > (authenticated by a client id and a secret). When the access token coming > with a request at the API, only the provider or an agent of the provider > knows what it is. Again IIRC, the provider doesn't know what the token is. The *client* does. The provider just passes a message saying "Access to the X Files, which you own, have been requested. Is that OK?" In practice, the common case is that consumer == owner, so effectively the message boils down to, "Click OK if you are you". > What I'm saying is that if OAuth is supported, mailman will be a part of > provider because it holds and protects the user's data. OAuth providers don't know about the protected data. OAuth consumers do. The provider-client combination only offers a communication channel. That's what is so elegant about the OAuth concept. Steve

2 1

Re: [Mailman-Developers] Architecture for extra profile info
by Richard Wackerbarth 27 Apr '13

27 Apr '13

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(a)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(a)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(a)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(a)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_A…> - >> 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(a)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(a)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(a)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

2 1

Re: [Mailman-Developers] Architecture for extra profile info
by Stephen J. Turnbull 27 Apr '13

27 Apr '13

Xu Wang writes: > 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 :-( No, we don't *need* to implement *anything*. We implement what we want to. That's the nature of a volunteer project. I'm recommending against becoming a provider because I think it's too hard to provide the enterprise-strength implementation you focus on. The client side is much easier. > 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). Yes, if I understand you correctly. > 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. It very much depends on how accurate the identification of the client needs to be. For an open subscription service where the only thing you really need to do is confirm ownership of the subscribed address, any provider the user trusts is good enough. > This will also make the API less "independent" because it is depending on > the provider service and provider's auth system. Why? The whole point of the OAuth protocol is that the authentication is delegated to an OAuth client, which contacts the provider, and if successful returns a token to the customer. The customer then interprets that token as it likes. The tokens have a specific, well-known form, so the authentication subsystem is completely independent of the application API. There does need to be coupling to the UI, to provide a channel to the OAuth provider. > Only if there is a strong 3-legged auth use case, should one push to this > controversy route. I don't see 3-legged auth as the killer app for OAuth here. Rather, I see convenience for subscribers as the main feature, although it might also be useful for moderators and other admins. Steve

2 1

Re: [Mailman-Developers] Architecture for extra profile info
by Richard Wackerbarth 27 Apr '13

27 Apr '13

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 <xuwang(a)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 <stephen(a)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(a)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(a)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

1 0

Re: [Mailman-Developers] Architecture for extra profile info
by Xu Wang 27 Apr '13

27 Apr '13

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(a)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(a)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(a)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_A…> - > 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(a)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(a)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 >> > >

1 0

Re: [Mailman-Developers] Architecture for extra profile info
by Stephen J. Turnbull 27 Apr '13

27 Apr '13

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.

2 2

Re: [Mailman-Developers] GSOC Project idea: OpenPGP integration
by Stefan Schlott 27 Apr '13

27 Apr '13

On 25.04.2013 00:14, Abhilash Raj wrote: > 1) When a message is decrypted and then passed on between the queues, it > creates a security threat for the cleartext message is being held in > memory, even for a small time in between the runners. The Mailman server holds the key to decrypt _every_ incoming message. So if the server is compromised, a message temporarily held in memory is the least of your problems :-) Stefan.

6 9

Re: [Mailman-Developers] Architecture for extra profile info
by Stephen J. Turnbull 27 Apr '13

27 Apr '13

Florian Fuchs writes: > If the instance of the user store does not act as provider, we would either: > > 1) effectively require every api user to have an account with some > other oauth provider. Most people do. Sites that care can bring up their own provider. AFAIK that's not terribly hard, and I doubt that Mailman can make it much easier. But we shouldn't encourage it. Requiring a specific provider sucks if not necessary for security reasons; users just end up managing yet another password and get no benefit. Adding a new provider, even if not required, is likely to cause the same problem if the user later signs up with a well-known provider. The point of OAuth for Mailman is that it's nearly formally equivalent to the traditional 3-part handshake (request subscription, receive token by mail to subscribed address, return token thus proving you are owner of the address), since most OAuth providers are email providers. Perfect fit. > or > > 2) use some other authentication method. What's wrong with HTTPS + Basic Auth? > Anyway, we're talking about something that is absolutely not needed > for what we want to achieve *right now*, which is a profile data store > that Postorius/HK/etc can access from localhost (or maybe from an > internal network. Or IP-restricted through SSL. Or... ?). OAuth (or Persona, etc) access for subscribers (to Postorius and HyperKitty) using subscribers' existing OAuth provider is not *absolutely* needed, but would be a very big plus. Users hate managing passwords for resources they don't care much about security. Once we've got that, I would think it's a relatively small step (in terms of code) to implementing for inter-component communications. The security audit required might be quite a bit of work, so we might not recommend deploying the feature in "high" security contexts.

4 3

Re: [Mailman-Developers] GSOC Project idea: OpenPGP integration
by Stephen J. Turnbull 25 Apr '13

25 Apr '13

Abhilash Raj writes: > Can you tell about who is going to mentor this(OpenPGP integration with > mailman) I would guess the official mentors are likely to be myself and Wacky (Richard Wackerbarth). Joost isn't official (why not? -- you get a T-shirt! :-) but he has expressed interest and offered help. Lack of a secure through-the-mail channel for several aspects of Mailman is a pain point for many users, though, so I suspect there will be a lot of interest (including suggestions and even code contributions) from non-mentors. I strongly suggest that you keep the discussion on this list for that reason. I will also try to be available on IRC Freenode #mailman as yaseppochi for the next two days (more or less 1am to 1pm UTC), and intermittently after that. Other mentors will probably be there, too. > so that I can discuss a few things about the application? Also > others can you please give me a few suggestion about proposal on > the idea that is discussed in this[1] thread. > > [1]: > http://mail.python.org/pipermail/mailman-developers/2013-April/022675.html > > Thanks, > > > On Wed, Apr 10, 2013 at 3:09 PM, Joost van Baal-Ilić < > joostvb-mailman-developers(a)mdcc.cx> wrote: > > > Hi Abhilash Raj, > > > > Abhilash Raj raj.abhilash1 at gmail.com schreef: > > >On Sun, Apr 7, 2013 at 4:47 AM, Daniel Kahn Gillmor > > ><dkg at fifthhorseman.net>wrote: > > >> On 04/06/2013 06:53 PM, Paul Wise wrote: > > >> > On Sun, Apr 7, 2013 at 5:19 AM, Abhilash Raj wrote: > > >> > > > >> >> I am a undergrad student interested in OpenPGP integration in mailman > > >> >> as a GSOC project this summer. > > > > >> neat, i'm glad to hear it! > > > > Be aware however: it's not an easy task, as Daniel Kahn Gillmor pointed > > out. > > > > >> > I'm not sure about the scope of your project but you may want to > > >> > review some prior efforts: > > >> > > > >> > http://schleuder2.nadir.org/ > > >> > http://www.synacklabs.net/projects/crypt-ml/ > > >> > > >> see also: > > >> > > >> http://non-gnu.uvt.nl/mailman-pgp-smime/ > > >> http://sels.ncsa.illinois.edu/ > > >> > > >> > My pet favourite feature from the lurker mail archiver is showing > > >> > photos from OpenPGP keys in the archive pages. > > >> > > >Thanks for these links. I am currently going through these projects to > > >figure out the implementation part of the OpenPGP into mailman. Also > > trying > > >to use the mailman-php-smime patch to figure out how it is implemented. > > > > The Mailman Secure List Server Patch hasn't been touched since 2010-09. > > It's a > > patch for mailman-2.1.15, not for the development branch. However, > > studying it > > will surely give you some inspiration. Some code might be reusable too. > > > > If you'd like to discuss details of this patch, you're invited to join the > > list > > at ssls-dev(a)ulm.ccc.de. > > > > I'd be glad to help you dealing with the work. > > > > Bye, > > > > Joost > > > > -- > > http://mdcc.cx/ x http://ad1810.com/ > > > > > > -- > Abhilash Raj > _______________________________________________ > Mailman-Developers mailing list > Mailman-Developers(a)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/stephen%40xemacs.… > > Security Policy: http://wiki.list.org/x/QIA9

3 2