subject:"\[Mailman\-Developers\] Architecture for extra profile info"

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
___
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

Re: [Mailman-Developers] Architecture for extra profile info


On Apr 27, 2013, at 9:15 AM, Stephen J. Turnbull step...@xemacs.org wrote:

 Richard Wackerbarth writes:
 
 It is not necessary to have more than a flat collection of lists.
 
 I don't know how it will be represented, but we *do* need to support
 virtual hosting, where the mailman administrator delegates site
 administration to the owner of the virtual host.

A list is a first class object. Each list has its own set of parameters which 
characterize it.
One portion of those characteristics is the administrative permissions 
associated with the creation and alteration of the list.

Groupings of lists simply provides a shorthand for the description of 
characteristics which are common to the group.

 In fact, that approach has the advantage that each list can be
 allowed to have individual configuration parameters. At the
 present, he has attached the base web URL to the
 email_domain. Instead, I would like to have the ability to set that
 on a per-list basis.
 
 I think that's reasonable.
 
 Rather than defining a specific structure, I would substitute a
 more generic structure defining collections of lists. This tree
 could be configured to represent any organizational hierarchy that
 the installation desires.
 
 Such flexibility has benefits and costs.  How many of our users will
 need/want this flexibility?  (Genuine question.  I personally don't
 want it, so it's hard for me to estimate.)

The advantage in using the generic structure is that it does not impose any 
pre-supposed structure on the collection of lists.
Note that core doesn't NEED the structure to function. The structure can be 
imposed by having the interface agent impose constraints on the members of a 
group of lists and mapping an operation on the group into that operation on 
each of its members.

If we use a MPTT key as the list/list-group identifier, we get the generic 
hierarchy as a byproduct.

The only real issue is how we would express constraints that get delegated.

But we need to address that issue for any structure that we establish.

Virtual hosting is the primary example of the need for a hierarchical 
administrative structure. However, it can also be useful in corporate 
structures where the email address space might be partitioned in a quite 
different manner.

From a design perspective, the core message handler should be distinct from 
the configuration administrator.
Message handling uses the current value of various configuration parameters. It 
need not, and should not be concerned with the mechanics related to the setting 
or modification of those parameters.

Since these parameters seldom change, an effective caching mechanism would 
address access performance issues.

___
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

Re: [Mailman-Developers] Architecture for extra profile info

On Apr 27, 2013, at 10:36 AM, Stephen J. Turnbull step...@xemacs.org wrote:
 Richard Wackerbarth writes:
 Primary Key == An identifier of the server's choice that identifies
 a unique instance of the specified resource.  It is important to
 note that the client CANNOT rely on any particular scheme for
 mapping other keys to this identifier.
 
 That's true for resources that were added after the client was
 written, but there's no reason I can see why we shouldn't make it easy
 for people to write URIs by hand if they know something about Mailman.

Being able to write URIs by hand is a violation of the HAL design because it 
locks the interface into a particular implementation. The design principal is 
that things will change.

Although there is an advantage in having URIs that convey semantic value, (for 
example using a short name to designate one of the lists on the server), we 
should leave that mapping to some configuration aspect of the particular 
installation.

Remember that the REST URIs are intended to be mechanisms for automated agents 
to access resources. They are not intended to be the substitute for a user's 
search interface.
___
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

Re: [Mailman-Developers] Architecture for extra profile info

On Apr 28, 2013, at 2:15 AM, Stephen J. Turnbull step...@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).

In many installations, the linking may not require the email handshake.
An installation may choose to trust that the third party issuing the access 
credential has already performed sufficient vetting of the association.

I'm thinking of things like BrowserID credentials or Google/Twitter/Facebook 
issued credentials.

However, that is a local policy whose decision involves a tradeoff between 
the level of assurance and the ease in establishing the association.
___
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

Re: [Mailman-Developers] Architecture for extra profile info

Richard Wackerbarth writes:

  Groupings of lists simply provides a shorthand for the
  description of characteristics which are common to the group.

You don't need to teach Grandma how to suck intensional
vs. extensional Python eggs.

   Such flexibility has benefits and costs.  How many of our users will
   need/want this flexibility?  (Genuine question.  I personally don't
   want it, so it's hard for me to estimate.)
  
  The advantage in using the generic structure is that it does not
  impose any pre-supposed structure on the collection of lists.

Ie, the advantage of being generic is that it's generic.

  Note that core doesn't NEED the structure to function.

Of course not, the only structure we NEED is a tape that's lightyears
long, and a finite automaton that Turing designed in the 40s IIRC.
Sorry for the sarcasm (well, a little bit sorry), but in deciding on
design principles we need to evaluate simplicity, practicality, etc
from the point of view of the people involved.

The question is whether structure makes the program easier for users
to use and for developers to create and maintain.  I think the tried
and true hierarchy (site - virtual hosts - lists) matches some a
natural hierarchy in administrative responsibility and user
understanding of this corner of the Web.  That makes it easier to
think about requirements and write code to satisfy them.

  The structure can be imposed by having the interface agent impose
  constraints on the members of a group of lists and mapping an
  operation on the group into that operation on each of its members.

Yes, and we'll have to create a language to express those constraints
and an interpreter to enforce them, *and* create objects like site
== Mailman instance and vhost out of the abstract groups.  Costs,
benefits, which is bigger?

  If we use a MPTT key

Ministry of Posts, Telegraph, and Telephone?  mildly paranoic teletype?

  as the list/list-group identifier, we get the generic hierarchy as
  a byproduct.

No, that's not enough.  Sites and virtual hosts have attributes
besides lists (websites, the mailman list, owner and admin
addresses, ...).  There should be objects that correspond to those
concepts to carry those attributes.

  The only real issue is how we would express constraints that get
  delegated.
  
  But we need to address that issue for any structure that we
  establish.

True, but it's not a question of need to or not, it's a question of
costs and benefits.  Generic code is more expensive to create and
maintain in many cases.  I suspect it will be here, as well.  Without
use cases for the generality, it's hard to see the benefits.  When do
you expect the generality to be of use?

  Virtual hosting is the primary example of the need for a
  hierarchical administrative structure. However, it can also be
  useful in corporate structures where the email address space might
  be partitioned in a quite different manner.
  
  From a design perspective, the core message handler should be
  distinct from the configuration administrator.
 
  Message handling uses the current value of various configuration
  parameters. It need not, and should not be concerned with the
  mechanics related to the setting or modification of those
  parameters.
  
  Since these parameters seldom change, an effective caching
  mechanism would address access performance issues.

I have no clue what you're trying to express here.  I don't see any
performance issues, except that programmers whose brains have exploded
from cognitive overload tend not to produce double-digit KLOC/hour.
My concern is entirely whether the design you propose simplifies the
job of meeting the common requirement of creating a (1 to 3 level)
hierarchical organization of lists (the third level being the children
of umbrella lists), or serves important use cases without
significantly complexifying the job of serving the common case.

I don't see a simplification for the reasons expressed above.

What are the use cases for a more generic structure?


___
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

Re: [Mailman-Developers] Architecture for extra profile info

Richard Wackerbarth writes:

  Being able to write URIs by hand is a violation of the HAL design
  because it locks the interface into a particular implementation.

Sorry, that's an un-Pythonic way to think.  If HAL really requires
URIs that only a machine can deal with, let's junk it.  If the
implementation is hard to explain, it's a bad idea.

But I really don't think HAL requires that.

___
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

Re: [Mailman-Developers] Architecture for extra profile info

2013-04-28 Thread Xu Wang

On Sun, Apr 28, 2013 at 11:27 AM, Stephen J. Turnbull step...@xemacs.orgwrote:

 Xu Wang writes:
   On Sun, Apr 28, 2013 at 12:15 AM, Stephen J. Turnbull 
 step...@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: step...@xemacs.org;
 email:stephen.turnbull...@u.tsukuba.ac.jp; owner:
 fs-p...@turnbull.sk.tsukuba.ac.jp; owner: xemacs-b...@xemacs.org ...;
 OpenID: stephenjturnb...@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.
___
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

Re: [Mailman-Developers] Architecture for extra profile info

Richard Wackerbarth writes:

  Yes, initially generating a more generic structure than the ad hoc
  one in place (which doesn't even attempt to address delegation)

Aha!  Something that looks like a concrete use case!  But what is
delegation?  I mean, who delegates what to whom?  And why does
Mailman need to address it?  What code needs to be written to address
it?

The rest of your post is just a reiteration of your religious belief
that generic is good.

I know the theory, but without use cases I will devote my efforts
elsewhere, and ignore complaints that my code or my advisee's code is
insufficiently general or that it ignores a theoretical design that
has no code or use case to back it up.
___
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

Re: [Mailman-Developers] Architecture for extra profile info

Xu Wang writes:

  No OpenID does not uses OAuth protocol.

My mistake.

Let's talk about what Mailman needs, then.  OpenID (or an equivalent
based on a more general system) is all that Mailman needs as far as I
can see.  AIUI, the resources that can be accessed or mutated, in
order of frequency of use, are

1. Moderation queues.  Moderators need access.  List owners grant
   access on the basis of identity of the moderator.

2. Subscriptions.  Subscribers and list owners need access.
   Subscribers usually own the subscribed address and have a privacy
   (no spam) right.  (In employment and education cases, subscribers
   may have restricted rights, but ID == authorization holds.)  List
   owners are delegated authority from site (or vhost) admin.  They
   may have legal (or precedent) rights to the subscriber list and
   archives.  Either way, ID is authorization.

3. Lists.  List owners need access.  List owners are delegated
   authority from site (or vhost) admin.  ID is authorization.

4. Virtual hosts (vhosts).  A namespace for lists based on a domain
   name (DNS MX).  Delegated by site admins.  ID is authorization.

5. Site (collection of vhosts).  A physical system.  Delegated to site
   admin from outside.  ID is authorization.

Corner cases: (1) People with multiple roles may prefer to have to
re-login (or su) use higher privilege.  su or sudo mechanisms
can address this.  (2) Delegators may wish to de-authorize
delegatees.  An ID-based authorization means some lag.  This can be
mitigated by granting authorization with short expiration, but that
has its issues too.

  Mailman can't use GMail as OAuth provider to protect mailman's own
  resource as a general authorization solution.

Evidently it can't use it at all, if OpenID isn't based on OAuth (and
the OAuth protocol exposed to GMail users).

  As you put it,  mailman don't have to support OAuth, but if it dose, it's
  better stick to the protocol.

I don't see how anything general I said doesn't stick to protocol.

*Validation* is a syntactic operation.  Contacting the resource owner
and asking is this token one of yours? is one way to validate.
(Traditional 3-way handshake for validating mail addresses when
subscribing is exactly this.)  But using encryption or signatures is
another way.

  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.

AFAICS this is all we need, see above.
___
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

Re: [Mailman-Developers] Architecture for extra profile info

I am thinking of delegation in the context of administering list properties 
and preferences.

Assume a hierarchy of lists handled by one (or more) servers that comprise a MM 
system.

Various persons could be assigned authority to make changes that affect lists 
within portions of the tree.
those changes might in things such as setting the default language or the 
ability to create a new list.

In the virtual hosting scenario, provides a number of possible opportunities to 
illustrate how this might be used.

The root of the tree covers all of the lists.
Under that top node, we might create nodes for Customer Plans, for example, 
Bronze, Silver, Gold and Platinum.
Each of these nodes would specify some limits that applies to the level of 
service.
Let us assume that the Bronze service plan allows the customer to have only 
lists set up by the Provider staff.
That user might still be allowed to set other parameters, for example, the 
subscription policy and thewelcome message.
Under the Silver Plan, a customer might be allowed to set up new lists within 
their own email-domain.

In both of these cases, a subordinate node would be created under the 
appropriate plan node for the list(s) of that customer.
And under those nodes, we would find various individual lists.

Now, within our permissions system, we would grant the customer administrator 
permissions to alter certain parts of the list parameters. In my example case, 
the right to create new lists would not be granted to the customers in the 
Bronze plan, but would be granted to those in the Silver plan.

Another right is the ability to permit the administrator to associate 
additional persons to nodes within their portion of the tree.
By doing so, that administrator delegates the ability to perform certain 
operations to this added person.

Note: I am not trying to present the complete set of details, only trying to 
indicate how such a framework might be utilized.

The reason that a generic mechanism has value is that the same type of 
permissions logic is utilized for any parameter describing the list behavior. 
Whether you are selecting the default user preference to receive digest or 
specifying the email address or website URL through which someone can 
unsubscribe, except for the filtering on permissible data values, the 
mechanisms needed to handle an input form are very similar.


Richard

On Apr 28, 2013, at 6:54 PM, Stephen J. Turnbull step...@xemacs.org wrote:

 Richard Wackerbarth writes:
 
 Yes, initially generating a more generic structure than the ad hoc
 one in place (which doesn't even attempt to address delegation)
 
 Aha!  Something that looks like a concrete use case!  But what is
 delegation?  I mean, who delegates what to whom?  And why does
 Mailman need to address it?  What code needs to be written to address
 it?
 
 The rest of your post is just a reiteration of your religious belief
 that generic is good.
 
 I know the theory, but without use cases I will devote my efforts
 elsewhere, and ignore complaints that my code or my advisee's code is
 insufficiently general or that it ignores a theoretical design that
 has no code or use case to back it up.

___
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

Re: [Mailman-Developers] Architecture for extra profile info


On Apr 28, 2013, at 6:54 PM, Stephen J. Turnbull step...@xemacs.org wrote:
 The rest of your post is just a reiteration of your religious belief that 
 generic is good.

Call it religion if you wish. It is based on DECADES of experience, many of 
which involved reworking existing code to handle some changed conditions.

 I know the theory, but without use cases I will devote my efforts
 elsewhere, and ignore complaints that my code or my advisee's code is
 insufficiently general or that it ignores a theoretical design that
 has no code or use case to back it up.


Where is your design to handle the delegation of (restricted) permissions to 
alter list settings, create new lists, add moderators or administrators, etc.?

I am, at least, proposing a framework which would be able to address these 
issues.

This sounds as if you are using the But you haven't actually built the entire 
system, therefore I can dismiss anything that you propose as a design concept 
excuse to dismiss any ideas that are Not Invented Here
___
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

Re: [Mailman-Developers] Architecture for extra profile info

My understanding of the use of oAuth to provide login information from 
Google, Twitter, etc. is based on the following description provided by Google.

Below is a trivial example of how to use Google's OAuth 2.0 endpoint to gain 
access to a Google API. It's a Python web application running on App Engine. 
The flow of the example is fairly straightforward:
When the application loads, it shows the you a Login link.
When you click that link, you are asked to login to Google and asked to release 
basic account information to the application (user consent).
If you grant consent, the application receives an access token.
Once it has the access token, the application presents the access token to the 
Google API that provides basic account information 
(https://www.googleapis.com/oauth2/v1/userinfo)
The application renders the basic account information in a simple table.
In particular, a user grants our server the permission to access some 
information pertaining to the user as it is stored by Google and accessed 
through their API for the purpose.

Based on that information, our server grants permission to the user thus 
identified and based on authorization data stored in our system. Once we have 
identified the user, our system can use tokens such as session keys, or other 
mechanisms, to maintain the association.

Richard

On Apr 28, 2013, at 2:42 PM, Xu Wang xuw...@gmail.com wrote:

 On Sun, Apr 28, 2013 at 11:27 AM, Stephen J. Turnbull 
 step...@xemacs.orgwrote:
 
 Xu Wang writes:
 On Sun, Apr 28, 2013 at 12:15 AM, Stephen J. Turnbull 
 step...@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: step...@xemacs.org;
 email:stephen.turnbull...@u.tsukuba.ac.jp; owner:
 fs-p...@turnbull.sk.tsukuba.ac.jp; owner: xemacs-b...@xemacs.org ...;
 OpenID: stephenjturnb...@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.

Re: [Mailman-Developers] Architecture for extra profile info

Richard Wackerbarth writes:

  The root of the tree covers all of the lists.  Under that top
  node, we might create nodes for Customer Plans, for example,
  Bronze, Silver, Gold and Platinum.  Each of these nodes
  would specify some limits that applies to the level of service.

But here the limits apply to *principals*[1], not lists, AFAICS.
Sure, you can record them on the lists, but you'll still have to check
the principal's ID/authorization (presumably site admins can do
anything they want, even to a list owned by a Bronze customer who
can't do it for himself.  Note how you repeatedly write [principal]
be allowed:

  Let us assume that the Bronze service plan allows the customer to
  have only lists set up by the Provider staff.  That user might
  still be allowed to set other parameters, for example, the
  subscription policy and thewelcome message.  Under the Silver
  Plan, a customer might be allowed to set up new lists within their
  own email-domain.
  
  In both of these cases, a subordinate node would be created under
  the appropriate plan node for the list(s) of that customer.  And
  under those nodes, we would find various individual lists.

I could see this organization being usable in a case where a customer
wants to have some Bronze-plan lists and some Gold-plan lists.
However, I could also abstract customer as a principal which is a
group of accounts with a common billing address.  Then accounts would
be authorized, and the customer would log in as an account-user as
appropriate, rather than log in as a customer-user.  The user
interface could provide a su-like way to switch accounts of a single
customer, and/or a sudo-like way to work with foreign accounts.

It's not obvious to me that your way of doing things is better for
this use-case.  If it's not plausible that it's better (I make no
claim that it's not at this point), it fails to justify an experiment
with a generic organization for lists.

  Another right is the ability to permit the administrator to
  associate additional persons to nodes within their portion of the
  tree.  By doing so, that administrator delegates the ability to
  perform certain operations to this added person.

This is more plausible as a use-case, since the certain nodes need
not be all the nodes for that administrator.  OTOH, we already have
list owner and moderator roles, and those *are* attached to each
list.  It's not clear to me that we need to provide for adding
additional roles, but I'll keep it in mind.



Footnotes: 
[1]  A generic term covering users, groups of users, accounts, and in
general entities that can be authorized.

___
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

Re: [Mailman-Developers] Architecture for extra profile info

2013-04-28 Thread Xu Wang

Well, it is about how a third party web application can get user's profile
data from google as oauth client, like OpenID,  it's little help on the
access control of a third party RESTful API.

As oauth supported google's userinfo API, one need to present a valid
google's oauth access token to get access.
s/google/mailman/g  on above statement, it will be true too.

If we are talking about enable OpenID or get user's profiles from google,
facebook, tweeter, etc. as an OAuth client in postorius, it should not be a
big deal because the client libs are readily available from those
providers, but it is different from claiming
mailman's api supports OAuth.


On Sun, Apr 28, 2013 at 6:47 PM, Richard Wackerbarth r...@dataplex.netwrote:

 My understanding of the use of oAuth to provide login information from
 Google, Twitter, etc. is based on the following description provided by
 Google.

 Below is a trivial example of how to use Google's OAuth 2.0 endpoint to
 gain access to a Google API. It's a Python web application running on App
 Engine. The flow of the example is fairly straightforward:

1. When the application loads, it shows the you a Login link.
2. When you click that link, you are asked to login to Google and
asked to release basic account information to the application (user
consent).
3. If you grant consent, the application receives an access token.
4. Once it has the access token, the application presents the access
token to the Google API that provides basic account information (
https://www.googleapis.com/oauth2/v1/userinfo)
5. The application renders the basic account information in a simple
table.

 In particular, a user grants our server the permission to access some
 information pertaining to the user as it is stored by Google and accessed
 through their API for the purpose.

 Based on that information, our server grants permission to the user thus
 identified and based on authorization data stored in our system. Once we
 have identified the user, our system can use tokens such as session keys,
 or other mechanisms, to maintain the association.

 Richard

 On Apr 28, 2013, at 2:42 PM, Xu Wang xuw...@gmail.com wrote:

 On Sun, Apr 28, 2013 at 11:27 AM, Stephen J. Turnbull step...@xemacs.org
 wrote:

 Xu Wang writes:

 On Sun, Apr 28, 2013 at 12:15 AM, Stephen J. Turnbull 

 step...@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: step...@xemacs.org;
 email:stephen.turnbull...@u.tsukuba.ac.jp; owner:
 fs-p...@turnbull.sk.tsukuba.ac.jp; owner: xemacs-b...@xemacs.org ...;
 OpenID: stephenjturnb...@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

Re: [Mailman-Developers] Architecture for extra profile info

Richard Wackerbarth writes:
  
  On Apr 28, 2013, at 6:54 PM, Stephen J. Turnbull step...@xemacs.org wrote:
   The rest of your post is just a reiteration of your religious
   belief that generic is good.
  
  Call it religion if you wish. It is based on DECADES of
  experience,

So are most religions, but for some reason they all have exceptions
where the Power chooses not to perform miracles.

  many of which involved reworking existing code to
  handle some changed conditions.

Of course you do.  Anybody with five years of experience has run into
that.  But with decades of experience, surely you've also run into
projects that never saw the light of day because the implementers
overengineered Grand Designs which didn't address user requirements.

  Where is your design to handle the delegation of (restricted)
  permissions to alter list settings, create new lists, add
  moderators or administrators, etc.?

Mailman 2.1.  I've seen no real reason to suppose we need more.  What
people repeatedly request on Mailman channels (in my, eminently
fallible, recollection) is more *power* for existing administrator
roles (viewing logs), more power for the user role (searching
archives), and more intuitive UIs for both.  Barry's design for
Mailman 3 addresses those needs by making it a heck of a lot easier
to experiment with additional UIs.

An example of a use case I don't like is the Like buttons (or
something like that) the HyperKitty guys are putting in.  Nobody has
requested them on Mailman channels that I can recall.  But social
networks are booming, and any visit to YouTube will provide evidence
that people do use those Like buttons, and comment on them.  I have
no ground to stand on there.  I'm sure those buttons will be
appreciated and used by lots of subscribers.  That use case is valid,
whatever my personal feeling is.

But I've never seen (IMEFR) a request for more flexibility in
constructing an administrative organization for a Mailman site.

  I am, at least, proposing a framework which would be able to
  address these issues.

My point is, Don't tell me about theoretical issues.  What use cases
are you addressing?  If users aren't going to use your framework,
there's no point in building it.

  This sounds as if you are using the But you haven't actually built
  the entire system, therefore I can dismiss anything that you
  propose as a design concept excuse to dismiss any ideas that are
  Not Invented Here

You're not listened if that's what it sounds like to you.  I haven't
once asked you for running code.  I've asked you for examples of what
Real Users[tm] might want to run the proposed code for.

If you want to build it with your own resources, I have no problem
with that.  If you want me to help, or if you want me to support your
design to other developers (including GSoC interns), I need to know
what it's for, besides addressing issues that I do perceive in
software engineering theory, but not in Mailman practice.

Steve
___
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

Re: [Mailman-Developers] Architecture for extra profile info

On Apr 28, 2013, at 9:58 PM, Stephen J. Turnbull step...@xemacs.org wrote:

 Richard Wackerbarth writes:
 
 The root of the tree covers all of the lists.  Under that top
 node, we might create nodes for Customer Plans, for example,
 Bronze, Silver, Gold and Platinum.  Each of these nodes
 would specify some limits that applies to the level of service.
 
 But here the limits apply to *principals*[1], not lists, AFAICS.

That is the case in my hypothetical example. However, the mechanism applies to 
any property of the lists such as a default value for some user preference.  In 
my example, the property is, perhaps, Administrator can/cannot create a new 
list
Equally, the content of a Greeting Message or the Default Language, or any 
other property can be treated in the same manner.

 I could see this organization being usable in a case where ...

 It's not obvious to me that your way of doing things is better for
 this use-case.  If it's not plausible that it's better (I make no
 claim that it's not at this point), it fails to justify an experiment
 with a generic organization for lists.

You seem to be missing the point that one size fits all, or in this case, one 
hierarchy, is not a flexible strategy.
By having a generic structure and allowing each installation to customize the 
hierarchy to fix their individual need, we provide a mechanism that better 
suits the needs of a larger group of installations.

 Another right is the ability to permit the administrator to
 associate additional persons to nodes within their portion of the
 tree.  By doing so, that administrator delegates the ability to
 perform certain operations to this added person.
 
 This is more plausible as a use-case, since the certain nodes need
 not be all the nodes for that administrator.  OTOH, we already have
 list owner and moderator roles, and those *are* attached to each
 list.  It's not clear to me that we need to provide for adding
 additional roles, but I'll keep it in mind.

I'm advocating that we attach the roles (whatever they may be) to an entire 
collection of lists.
The purpose of a hierarchical structure, whether one fixed structure or a 
generic recursive one, is to provide a mechanism to
assist the principal in managing a number of lists that have common 
properties.

Actually, by establishing a flexible hierarchy, it may be possible to eliminate 
some of the functionally similar roles. For example, a Domain Administrator 
might be nothing more than a List Administrator attached to a higher node in 
the tree of Lists.

___
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

Re: [Mailman-Developers] Architecture for extra profile info

Xu Wang writes:

  As oauth supported google's userinfo API, one need to present a valid
  google's oauth access token to get access.
  s/google/mailman/g  on above statement, it will be true too.

I disagree, in the sense that Google (as an OAuth provider) is in the
business of *providing* enterprise workflows such as AppEngine.
That's why they need to be an OAuth provider.  Mailman is a support
function for workflows (enterprise or otherwise).

So it's not a Mailman token.  It's an enterprise token, and the
enterprise, not Mailman, should be the provider.  If Mailman provides,
then we have to take responsibility for foreseeing enterprise needs.

If we go Wacky's route and make everything as generic as possible, we
may need the power of OAuth to handle all that genericity.  (We may
also then need another 5 years to release Mailman 3)  But if we
stick to the current role-based authorization model with a small fixed
set of roles, then OpenID-like workflows (whether implemented via
OAuth protocol or otherwise) should be enough.

If a site demands more control over authentication than public OpenID
providers can afford, then Basic Auth over HTTPS fits into the user
has role authorization model as well as OpenID does.  I don't see a
need for Mailman to provide an authentication provider, and there are
serious downsides to the proliferation of authentication providers.

Steve
___
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

Re: [Mailman-Developers] Architecture for extra profile info

Steve,

Here I agree with you.

It is useful for MM to be able to accept enterprise information when it is 
available.
OAuth is a mechanism that will be useful for some enterprises.
To the general public, being able to use enterprise identification from common 
sources such as Google or Twitter, is a friendly way identify a user and 
allow them to log into a MM system.

Within a MM installation, OAuth could be used in a more robust distributed 
implementation. However for our purposes, much simpler schemes such as Basic or 
Digest Auth is more than adequate for the intercommunication between components 
such as core, postorius, a message store, etc.

Richard

On Apr 28, 2013, at 11:07 PM, Stephen J. Turnbull step...@xemacs.org wrote:

 Xu Wang writes:
 
 As oauth supported google's userinfo API, one need to present a valid
 google's oauth access token to get access.
 s/google/mailman/g  on above statement, it will be true too.
 
 I disagree, in the sense that Google (as an OAuth provider) is in the
 business of *providing* enterprise workflows such as AppEngine.
 That's why they need to be an OAuth provider.  Mailman is a support
 function for workflows (enterprise or otherwise).
 
 So it's not a Mailman token.  It's an enterprise token, and the
 enterprise, not Mailman, should be the provider.  If Mailman provides,
 then we have to take responsibility for foreseeing enterprise needs.
 
 If we go Wacky's route and make everything as generic as possible, we
 may need the power of OAuth to handle all that genericity.  (We may
 also then need another 5 years to release Mailman 3)  But if we
 stick to the current role-based authorization model with a small fixed
 set of roles, then OpenID-like workflows (whether implemented via
 OAuth protocol or otherwise) should be enough.
 
 If a site demands more control over authentication than public OpenID
 providers can afford, then Basic Auth over HTTPS fits into the user
 has role authorization model as well as OpenID does.  I don't see a
 need for Mailman to provide an authentication provider, and there are
 serious downsides to the proliferation of authentication providers.
 
 Steve

___
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

Re: [Mailman-Developers] Architecture for extra profile info

Richard Wackerbarth writes:

  You seem to be missing the point that one size fits all, or in
  this case, one hierarchy, is not a flexible strategy.

Sorry, that's false, and there's plenty of evidence in the archives
that I've acknowledged that point.

But flexible is not an absolute, not even if you're discussing
female gymnasts.  My point is that IMHO it's flexible *enough*.

  I'm advocating that we attach the roles (whatever they may be) to
  an entire collection of lists.

I know what you're advocating, and I agree with the general theory of
constructing for flexibility.  I just don't see a need for it.

  Actually, by establishing a flexible hierarchy, it may be possible
  to eliminate some of the functionally similar roles. For example, a
  Domain Administrator might be nothing more than a List
  Administrator attached to a higher node in the tree of Lists.

Sure.  That's the main point of a generic model, sharing code to
handle cases that are similar enough to handle with the same code.

However, I don't think it's true that they're that similar.  By the
principle of subsidiarity, there are things that a List Administrator
does that a Domain Administrator normally shouldn't do (authorizing
moderators).  But there are others that both should be able to do
(clearing queues of broken messages, removing legally objectionable
messages from archives).

So to handle both attributes that are subject to subsidiarity and
those that aren't, you need as much code as in the current model,
*plus* in your model you need to make the code generic *and* provide
rules for the existing use cases.  That just doesn't sound like a
bargain to me in the absence of a few plausible *and concrete* use
cases that require more flexibility.

Steve
___
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

Re: [Mailman-Developers] Architecture for extra profile info

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/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] Architecture for extra profile info

Richard Wackerbarth writes:

  https://server.example.com/mailman/list/ABCDEFG/attribute/join_address
  returns the email address to which subscription requests should be
  sent.

ABCDEFG is what?  The list?

I think the short prefix /mailman/ should be reserved for traditional
and anonymous requests.  /mailman/rest_api/ or some such for the
REST API.

  https://server.example.com/mailman/list/ABCDEFG/attributes

This is what you mean by self-documenting?  Presumably it returns not
only the attribute names, but their ranges (types) and docstrings?

  https://server.example.com/mailman/attribute/posting_address/test_l...@example.com
   would return the URI representing the list

Why have you changed the order of components here?

  https://server.example.com/mailman/attribute/posting_address/test_l...@example.com/attribute/join_address
   might return test_list-j...@example.com

Huh?  This isn't a syntax error?

___
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

Re: [Mailman-Developers] Architecture for extra profile info

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 step...@xemacs.orgwrote:

 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

Re: [Mailman-Developers] Architecture for extra profile info

Here is my take on the basic system requirements and design issues:

System Components:
   * A RESTful 
APIhttps://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
authhttp://en.wikipedia.org/wiki/Basic_access_authentication,
username/pwd, requires https and minimum client effort.
- HMAC
authhttp://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
authhttp://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 HATEOAShttp://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.orgwrote:

 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

Re: [Mailman-Developers] Architecture for extra profile info

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: swesg...@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: auxri...@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 xuw...@gmail.com wrote:

 Here is my take on the basic system requirements and design issues:

 System Components:
* A RESTful 
 APIhttps://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 
 authhttp://en.wikipedia.org/wiki/Basic_access_authentication,
 username/pwd, requires https and minimum client effort.
 - HMAC 
 authhttp://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 
 authhttp://en.wikipedia.org/wiki/Hash-based_message_authentication_code

 Resource/Data model servered by API:
 * TBD,  means data model changes as-we-go.

Re: [Mailman-Developers] Architecture for extra profile info

On Apr 27, 2013, at 2:42 AM, Stephen J. Turnbull turnb...@sk.tsukuba.ac.jp
wrote:

Richard Wackerbarth writes:

https://server.example.com/mailman/list/ABCDEFG/attribute/join_address
returns the email address to which subscription requests should be
sent.

ABCDEFG is what? The list?

Yes. But note that it is some pk provided by the list store. It may not have
any recognizable relationship to other characteristics of the list ( such as a
common name or FQDN )

I think the short prefix /mailman/ should be reserved for traditional
and anonymous requests. /mailman/rest_api/ or some such for the
REST API.

I don't disagree. I would reserve /.well_known/mailman/ as an access point that
delivers the root of the REST API tree and, otherwise, make no assumption
about the location of it in URI space.

https://server.example.com/mailman/list/ABCDEFG/attributes

This is what you mean by self-documenting?

No. This is an access point for the document. If fetched as JSON or XML, it
would be machine parseable. If fetched as HTML/text, it would be human readable.

Presumably it returns not only the attribute names, but their ranges (types)
and docstrings?

https://server.example.com/mailman/attribute/posting_address/test_l...@example.com
would return the URI representing the list

Why have you changed the order of components here?

Because I don't know the pk for the list. I wish to look it up.

https://server.example.com/mailman/attribute/posting_address/test_l...@example.com/attribute/join_address
might return test_list-j...@example.com

Huh? This isn't a syntax error?

Probably is syntactically incorrect. The email address would need to be URL
escaped.

___
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

Re: [Mailman-Developers] Architecture for extra profile info

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 xuw...@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: swesg...@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: auxri...@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 xuw...@gmail.com wrote:
 
 Here is my take on the basic system requirements and design issues:
 
 System Components:
   * A RESTful 
 APIhttps://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 
 authhttp://en.wikipedia.org/wiki/Basic_access_authentication,
 username/pwd, requires https and minimum client effort.
- HMAC 
 authhttp://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

Re: [Mailman-Developers] Architecture for extra profile info

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 xuw...@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 
 step...@xemacs.orgwrote:
 
 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

Re: [Mailman-Developers] Architecture for extra profile info

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
___
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

Re: [Mailman-Developers] Architecture for extra profile info

On Apr 26, 2013, at 11:32 PM, Richard Wackerbarth r...@dataplex.net wrote:

 Additionally, I would generalize the grouping of lists into a hierarchical 
 tree that represents the enterprise organization rather than aspects of the 
 internet namespace.

Stephen,

Barry has introduced a small amount of hierarchy into the grouping of lists. 
(E.g. The domain)
Within that hierarchy, he at least alludes to the delegation of authority to 
list owners.

It is not necessary to have more than a flat collection of lists. In fact, that 
approach has the advantage that each list can be allowed to have individual 
configuration parameters. At the present, he has attached the base web URL to 
the email_domain. Instead, I would like to have the ability to set that on a 
per-list basis. There is no structural constraint that requires lists to share  
such common values, but I do acknowledge that it is expedient for the system to 
be able to generate the list specific value by some algorithm that is applied 
to a class of lists.

Rather than defining a specific structure, I would substitute a more generic 
structure defining collections of lists. This tree could be configured to 
represent any organizational hierarchy that the installation desires. Various 
persons could then be granted administrative rights over particular subtrees. 
Algorithmic constraints can be assigned to a collection insuring that each list 
therein complies with the enterprise schema.
___
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

Re: [Mailman-Developers] Architecture for extra profile info

Richard Wackerbarth writes:

   Ah so you don't mean what I wrote above, you want to represent
   preferences as a table with
   
  row = preference-owning-entity att_name att_key

  Correct. But isn't it
  
  row = preference-owning-entity att_name att_value

Yes.
___
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

Re: [Mailman-Developers] Architecture for extra profile info

Richard Wackerbarth writes:

   ABCDEFG is what?  The list?
  
  Yes. But note that it is some pk provided by the list store.

pk ?

   https://server.example.com/mailman/attribute/posting_address/test_l...@example.com
would return the URI representing the list
   
   Why have you changed the order of components here?
  
  Because I don't know the pk for the list. I wish to look it up.

So attribute/posting_address/test_l...@example.com is a query that
means give me a way to indicate this list?

These URIs are pretty ugly.  Surely we can do better?
___
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

Re: [Mailman-Developers] Architecture for extra profile info


On Apr 27, 2013, at 8:19 AM, Stephen J. Turnbull step...@xemacs.org wrote:

 Richard Wackerbarth writes:
 
 ABCDEFG is what?  The list?
 
 Yes. But note that it is some pk provided by the list store.
 
 pk ?

Primary Key == An identifier of the server's choice that identifies a unique 
instance of the specified resource.
It is important to note that the client CANNOT rely on any particular scheme 
for mapping other keys to this identifier.

 https://server.example.com/mailman/attribute/posting_address/test_l...@example.com
  would return the URI representing the list
 
 Why have you changed the order of components here?
 
 Because I don't know the pk for the list. I wish to look it up.
 
 So attribute/posting_address/test_l...@example.com is a query that
 means give me a way to indicate this list?

Yes

 These URIs are pretty ugly.  Surely we can do better?

Perhaps we can. But we need to conform to the HAL framework style.

As I understand it, the consumer understands the semantics of various links, 
but the actual links are discovered as a part of previous queries and not 
constructed.  As such, the links depend more on the ease of implementation 
rather than their beauty.

Perhaps Xu has experience and can enlighten us.

___
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

Re: [Mailman-Developers] Architecture for extra profile info

Richard Wackerbarth writes:

  It is not necessary to have more than a flat collection of lists.

I don't know how it will be represented, but we *do* need to support
virtual hosting, where the mailman administrator delegates site
administration to the owner of the virtual host.

  In fact, that approach has the advantage that each list can be
  allowed to have individual configuration parameters. At the
  present, he has attached the base web URL to the
  email_domain. Instead, I would like to have the ability to set that
  on a per-list basis.

I think that's reasonable.

  Rather than defining a specific structure, I would substitute a
  more generic structure defining collections of lists. This tree
  could be configured to represent any organizational hierarchy that
  the installation desires.

Such flexibility has benefits and costs.  How many of our users will
need/want this flexibility?  (Genuine question.  I personally don't
want it, so it's hard for me to estimate.)

___
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

Re: [Mailman-Developers] Architecture for extra profile info

Richard Wackerbarth writes:

  Primary Key == An identifier of the server's choice that identifies
  a unique instance of the specified resource.  It is important to
  note that the client CANNOT rely on any particular scheme for
  mapping other keys to this identifier.

That's true for resources that were added after the client was
written, but there's no reason I can see why we shouldn't make it easy
for people to write URIs by hand if they know something about Mailman.

   These URIs are pretty ugly.  Surely we can do better?
  
  Perhaps we can. But we need to conform to the HAL framework style.

Well, I haven't studied it carefully, but the examples on Mike Kelly's
pages are pretty enough.

  As I understand it, the consumer understands the semantics of
  various links, but the actual links are discovered as a part of
  previous queries and not constructed.  As such, the links depend
  more on the ease of implementation rather than their beauty.

From the consumer's point of view, yes, the links are discovered.  But
the producer constructs them.

___
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

Re: [Mailman-Developers] Architecture for extra profile info

On Sat, Apr 27, 2013 at 4:59 AM, Stephen J. Turnbull step...@xemacs.orgwrote:

 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.


Loud and clear.



 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.


Agreed.


   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.


The problem is how do you  confirm ownership of the subscribed address
when a request coming with an access token. In another words, unless your
are the provider, how do you validate the access token issued by a
provider at the resource endpoint?


   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.


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.

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.

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.


 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.

 Stev
___
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

Re: [Mailman-Developers] Architecture for extra profile info

On Sat, Apr 27, 2013 at 4:27 AM, Richard Wackerbarth r...@dataplex.netwrote:

 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. :)

 Totally agreed.

To be clear, what I gave was only some random test data of a testing data
schema from an early stage prototype for the purpose of concepture
discussion . Neither to be the real use case nor to be a substitution
of any existing working components.

I started with MySQL, but after playing around a bit, I do think a NoSQL
database is a good fit for this project. It will simplify the task quite a
bit.
___
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

Re: [Mailman-Developers] Architecture for extra profile info

2013-04-26 Thread Terri Oda


So... What have we decided? :)

From my fuzzy I read my email on a plane after delta woke me up at 3am 
to tell me my flight was cancelled level of recollection


The few things I we actually agreed on:

- We like the idea of a rest interface.

- That interface/API should probably be decided now and relatively 
permanently


- then implementation details can be changed later as necessary (so it 
doesn't matter if we start with django or whether mailman-user reads 
from mailman-core or vice versa, as long as it gets done and fulfills 
the promises of the API)


- something something oauth something

Can someone sketch out what that REST interface will look like as an 
actual architectural document that we can comment on?  I don't care who 
does this; we just need somewhere to start, so any subscriber to this 
list can probably summarize the emails into a useful document.


 Terri


___
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

Re: [Mailman-Developers] Architecture for extra profile info

2013-04-26 Thread Abhilash Raj

Hi all,
I wrote a brief summary[1] of this thread. Its in the form of notes sorted
according to participants and a small summary at the end( showing off
whatever I could understand reading the thread twice from head to toe ).
However I might have misunderstood ( or not understood at all ) or missed a
few things, forgive me for that.

[1]: https://gist.github.com/maxking/5471211

Thanks,
Abhilash


On Sat, Apr 27, 2013 at 1:06 AM, Terri Oda te...@zone12.com wrote:

 So... What have we decided? :)

 From my fuzzy I read my email on a plane after delta woke me up at 3am to
 tell me my flight was cancelled level of recollection

 The few things I we actually agreed on:

 - We like the idea of a rest interface.

 - That interface/API should probably be decided now and relatively
 permanently

 - then implementation details can be changed later as necessary (so it
 doesn't matter if we start with django or whether mailman-user reads from
 mailman-core or vice versa, as long as it gets done and fulfills the
 promises of the API)

 - something something oauth something

 Can someone sketch out what that REST interface will look like as an
 actual architectural document that we can comment on?  I don't care who
 does this; we just need somewhere to start, so any subscriber to this list
 can probably summarize the emails into a useful document.

  Terri



 __**_
 Mailman-Developers mailing list
 Mailman-Developers@python.org
 http://mail.python.org/**mailman/listinfo/mailman-**developershttp://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/http://www.mail-archive.com/mailman-developers%40python.org/
 Unsubscribe: http://mail.python.org/**mailman/options/mailman-**
 developers/raj.abhilash1%**40gmail.comhttp://mail.python.org/mailman/options/mailman-developers/raj.abhilash1%40gmail.com

 Security Policy: http://wiki.list.org/x/QIA9




-- 
Abhilash Raj
___
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

Re: [Mailman-Developers] Architecture for extra profile info

2013-04-26 Thread Richard Wackerbarth

Abhilash,

Thanks for the summary.

Let me add a bit about what I think we should present in this interface.

First, it should be RESTful and self documenting.

The format of information delivered will be controlled by the http Accept: 
header
The standard representation for communication between various modules of the MM 
system (core, user-manager,webUI, etc.) will be application/hal+json


https://server.example.com/mailman/list/ABCDEFG/attribute/join_address returns 
the email address to which subscription requests should be sent.

https://server.example.com/mailman/list/ABCDEFG/attributes

https://server.example.com/mailman/attribute/posting_address/test_l...@example.com
 would return the URI representing the list

https://server.example.com/mailman/attribute/posting_address/test_l...@example.com/attribute/join_address
 might return test_list-j...@example.com


See https://gist.github.com/hjr3/2289546 (an E-commerce platform specification) 
to get a representative idea of the json formatting.

I envision the simplified model to have the following core resources:

user -  A person
address - An email address each address is owned by one person
credential - An authentication binding associating a user with an identifier 
such as username/password, browserid, or oAuth

list - A mailing list. Lists have attributes that apply to the list and also 
have a set of preferences which supplies defaults for subscription preferences

subscription - the binding of an email address to a list.

attributes - a dictionary of the parameters that characterize the list

preferences - a dictionary of the parameters that apply to a subscription

I am suggesting two primary differences from the MM core style of 
representation.
First, rather than having multiple attributes and preferences as columns in a 
table, I would portray them as multiple rows in a table where the attribute 
names are a key that is used to select the corresponding value.

Additionally, I would generalize the grouping of lists into a hierarchical tree 
that represents the enterprise organization rather than aspects of the internet 
namespace.

By treating the preferences as a table of key-value pairs, we can easily extend 
the list of elements with plug-in modules without having to change the data 
handling or display mechanisms.

Richard

On Apr 26, 2013, at 7:00 PM, Abhilash Raj raj.abhila...@gmail.com wrote:

 Hi all,
 I wrote a brief summary[1] of this thread. Its in the form of notes sorted
 according to participants and a small summary at the end( showing off
 whatever I could understand reading the thread twice from head to toe ).
 However I might have misunderstood ( or not understood at all ) or missed a
 few things, forgive me for that.
 
 [1]: https://gist.github.com/maxking/5471211
 
 Thanks,
 Abhilash
 
 
 On Sat, Apr 27, 2013 at 1:06 AM, Terri Oda te...@zone12.com wrote:
 
 So... What have we decided? :)
 
 From my fuzzy I read my email on a plane after delta woke me up at 3am to
 tell me my flight was cancelled level of recollection
 
 The few things I we actually agreed on:
 
 - We like the idea of a rest interface.
 
 - That interface/API should probably be decided now and relatively
 permanently
 
 - then implementation details can be changed later as necessary (so it
 doesn't matter if we start with Django or whether mailman-user reads from
 mailman-core or vice versa, as long as it gets done and fulfills the
 promises of the API)
 
 - something something oauth something
 
 Can someone sketch out what that REST interface will look like as an
 actual architectural document that we can comment on?  I don't care who
 does this; we just need somewhere to start, so any subscriber to this list
 can probably summarize the emails into a useful document.
 
 Terri
 
 
 
 __**_
 Mailman-Developers mailing list
 Mailman-Developers@python.org
 http://mail.python.org/**mailman/listinfo/mailman-**developershttp://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/http://www.mail-archive.com/mailman-developers%40python.org/
 Unsubscribe: http://mail.python.org/**mailman/options/mailman-**
 developers/raj.abhilash1%**40gmail.comhttp://mail.python.org/mailman/options/mailman-developers/raj.abhilash1%40gmail.com
 
 Security Policy: http://wiki.list.org/x/QIA9
 
 
 
 
 -- 
 Abhilash Raj
 ___
 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/rkw%40dataplex.net
 
 Security Policy: http://wiki.list.org/x/QIA9

___

Re: [Mailman-Developers] Architecture for extra profile info

2013-04-26 Thread Stephen J. Turnbull

Richard Wackerbarth writes:

  subscription - the binding of an email address to a list.

Also preferences are bound here.  (This is not the only kind of thing
that preferences can be bound to, but experience shows that we need
per-subscription preferences.)

  First, rather than having multiple attributes and preferences as
  columns in a table, I would portray them as multiple rows in a
  table where the attribute names are a key that is used to select
  the corresponding value.

I have no clue what that sentence means, but I suppose that you mean
that the current representation is something like (in mock-ABNF)

member := address fullname *attribute

and you want to change that to

member := address fullname preferences
preferences := *attribute

  Additionally, I would generalize the grouping of lists into a
  hierarchical tree that represents the enterprise organization
  rather than aspects of the internet namespace.

Example?

  By treating the preferences as a table of key-value pairs, we can
  easily extend the list of elements with plug-in modules without
  having to change the data handling or display mechanisms.

Ah so you don't mean what I wrote above, you want to represent
preferences as a table with

row = preference-owning-entity att_name att_key

?
___
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

Re: [Mailman-Developers] Architecture for extra profile info

2013-04-19 Thread Richard Wackerbarth

Barry,

Are you starting to come around to the concept that I have been advocating for 
a long time?

In particular, rather than owning the user information, core simply views 
it.

I assume that you are reluctant to store foreign keys to external databases 
because you worry that consistency might be broken when another process alters 
the database.

I ask that you consideration the following as it applies to that view:
First, as viewed from the other side (the enterprise, etc.), your same concerns 
apply to accessing their user. For example, when you store the user password, 
how do they assure availability and consistency?

Second, particularly if you separate the administration functions, core 
message handling should, at most, rarely care about the user information. The 
subscription information, which seldom changes, should contain sufficient 
information to handle the time-critical task of message dispatch.

Richard
 
On Apr 18, 2013, at 8:20 PM, Barry Warsaw ba...@list.org wrote:

 Terri, thanks for kicking off this discussion!
 
 On Apr 18, 2013, at 01:34 PM, Terri Oda wrote:
 
 On 13-04-18 2:28 AM, Stephen J. Turnbull wrote:
 Main comment: Sounds like LDAP to me.
 
 Actually, this is a really important comment.  I was sort of wondering that
 too when I started writing the description.  LDAP is a moderately frequently
 requested feature already.  Would it make sense to use that probably rather
 than rest, or make a rest framework that talked to ldap under the hood?
 
 I agree that this is a really interesting suggestion.
 
 What's interesting to me about it is that this acknowledges that
 administrative control of this extra user information may fall to folks not at
 all directly involved in mailing list administration.
 
 You can imagine that a company would already have their LDAP database of
 additional user information, from postal addresses, to phone numbers, to IRC
 handles, pictures and icons, birthdays, etc.  Further, I can imagine that if
 that company were to be running MM3 and HyperKitty, they'd probably not want
 to duplicate that information in multiple databases, they'd just want to pull
 the pictures and IRC nicks out of LDAP.  For their purposes, their LDAP
 database *is* their user database.
 
 Of course, some of that information may also be used in part or in whole for
 the core, e.g. display names (which actually are useful in places, such as
 crafting the From header for a virgin notification).
 
 Now, at least conceptually, I've always thought about the user database as one
 of the three pillars of information in the core, the other two being the list
 database and the message store.  This is why for example subscriptions do not
 just link a foreign key for the mlist to a foreign key to the address, because
 this would not allow for separation of these two pillars[1].
 
 Furthermore, the use of interfaces internally is meant to allow for
 alternative implementations of the lowest database layer of these pillars,
 without affecting any functionality above it.  So let's say even in the core,
 user passwords, display names, and preferences were kept in LDAP.  An
 alternative implementation of user.py would pull the data in from there and as
 long as it satisfied the syntactic and semantic APIs of the IUser interface,
 everything else in MM3 would continue to work.
 
 You could extend this to the idea expressed elsewhere that the core could use
 this external user database.  Why not?  The external user database could be
 accessible over REST or a via a database server, etc.  We'd need an
 implementation of the underlying data objects that could talk to this user
 database and satisfy the interfaces, and that should be all you'd need.
 Making it performant enough for the core is just an engineering exercise
 wink.
 
 -Barry
 
 [1] Whether any of this works or has the right separation is another matter
 entirely. ;)  For example, looking at it now, I'm not so sure Members
 shouldn't be part of the MailingList pillar rather than the user database
 pillar.
 ___
 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/rkw%40dataplex.net
 
 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

Re: [Mailman-Developers] Architecture for extra profile info

On Apr 19, 2013, at 07:18 AM, Richard Wackerbarth wrote:

Are you starting to come around to the concept that I have been advocating
for a long time?

It's always been part of my thinking, and it's most evident in the use of
interfaces internally.  Time will tell whether we've accomplished that or
not.

However, it's also important to realize that probably the vast majority of
users who roll their own just install what we give them and go (well, most
likely with their stack of distro patches).  So I think in that case, it still
makes sense for the core to provide, by default, a minimally useful user
database, as it does today.

I ask that you consideration the following as it applies to that view: First,
as viewed from the other side (the enterprise, etc.), your same concerns
apply to accessing their user. For example, when you store the user
password, how do they assure availability and consistency?

It's a great question, which I cannot answer.  My opinion is that we have to
let such enterprise users drive that development, while we give them an
architecture that supports their use cases.

Second, particularly if you separate the administration functions, core
message handling should, at most, rarely care about the user
information. The subscription information, which seldom changes, should
contain sufficient information to handle the time-critical task of message
dispatch.

Our users (specifically IUser) is extremely minimal.  A user consists of a
display name, a password[1], an id, and a created on date.  There are some
additional methods or properties which are just convenient APIs for queries
and membership updates, but really it's not much more than a way to collate a
set of registered addresses under one unit.

-Barry

[1] With Persona, we can *probably* get rid of the password.  It's only going
to be used to do authenticated email commands, but it sucks for security.
It's also probably true that few people actually use the email command
interface - heck even I rarely use it.  It's important to keep, but I think it
would be better to base that on OpenPGP rather than plain text passwords.


signature.asc
Description: PGP signature
___
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

Re: [Mailman-Developers] Architecture for extra profile info

On Apr 18, 2013, at 10:26 AM, Terri Oda wrote:

I thinks case, case we have to be *much* more conservative about
dependencies.  I think Django would be right out as a dependency for Mailman
core, for example.  Plus, we're going to have to care a lot more about speed
and all.

Definitely.  However (and I'm not saying it has to be this way ;) if the user
database were a Django app, and there were REST APIs that the core could call
to do updates, then when something in the core changes, an event would get
triggered that would make the RESTish call to update the user database.
Similarly, when something in the user database changes that the core needs to
know about, it would call the core's REST API to make that change.

We would have to design something that would be robust enough to deal with
failures, but I think it could be done.

2. The user module reads from mm-core and augments it.

This gives us the ability to supplement mm-core without impeding speed.  We
discussed possibly filling in the blanks with respect to things like the user
preferences (which are currently set by membership, by user and by email
address... but a lot of those return an empty set when queried if nothing is
set directly there...) so this is maybe something we already want.

Conceptually, #1 is probably easier because everything will be in one place,
but if we do #2 right, we can make it just as conceptually easy for
HyperKitty/Postorius/etc. without impeding Barry's core dev at all.  That
does mean in case 2 that Mailman Extraneous User Stuff is going to depend on
Mailman Core, though.

Which I think is fine for now.  Without the core, what do you have? :)

a) It doesn't add any dependencies to Mailman core.

b) It doesn't require big changes in Mailman Core.  Given that core is pretty
much ready to release, now would be a bad time for changes, and I'm just not
sure we can justify that amount of work for the types of features that will
be built on the extraneous user stuff.

c) It will be much easier to rip this out and replace it when we better
understand our actual needs.  (e.g. Right now, I think a case could be made
that a quick mock-up in django would be fine, but I suspect that requiring
django for some potential applications would border on ridiculous)

We're probably going to be running around with a bit of a hack job for the
user database in the near future (either done by a student who needs it in a
hurry or done by one of the core devs to support a student who needs it in a
hurry) so while I don't like to design on the assumption it's going to go
wrong, I think in this case planning for a redesign might be prudent because
it's pretty clear we don't actually know all our requirements.

+1

-Barry
___
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

Re: [Mailman-Developers] Architecture for extra profile info

On Apr 18, 2013, at 09:39 PM, Florian Fuchs wrote:

I think in this case it makes sense to spend a more time on the API as
seen from the outside (urls, methods, json responses) than the actual
implementation. If the API is good, it's totally acceptable if the
underlying implementation will be redesigned later.

+1

-Barry
___
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

Re: [Mailman-Developers] Architecture for extra profile info

On Apr 19, 2013, at 10:22 AM, Stephen J. Turnbull wrote:

  2) use some other authentication method.

What's wrong with HTTPS + Basic Auth?

Oh, one thing about HTTPS + Basic Auth.  Right now, MM3 core has only one
admin user and password for access to its REST API.  So it can't be used to
authenticate individual users, only the root user of the REST API.

-Barry
___
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

Re: [Mailman-Developers] Architecture for extra profile info

2013-04-19 Thread Stephen J. Turnbull

Richard Wackerbarth writes:
  On Apr 18, 2013, at 8:25 PM, Stephen J. Turnbull step...@xemacs.org wrote:
   Richard Wackerbarth writes:

   Since we consider the user manager to be a part of the MM complex,
   what have we gained by hiding the underlying credential from the
   web interface?
   
   Security.  See the OAuth 2.0 spec (RFC 6749) which recommends (at
   SHOULD level) this practice.
  
  RFC 6749 addresses the implementation of an OAuth authorization
  system.
  
  In this context, SHOULD refers to the implementation of this RFC.
  
  It does not imply that other authorization schemes also need to
  meet those same criteria.

True, but logically irrelevant: it does not mean that the
recommendations of the RFC are irrelevant in the design of
authorization schemes.

OAuth has reasons for recommending that you avoid passing user-
supplied credentials around.  These include (among others I haven't
the imagination to supply here, I'm sure)

(1) privacy of the user (the component the user wants access to may
have no need to know who the user is)
(2) security of the user credentials (leaking the auth token does not
allow an attacker to access all resources the user is authorized
for)
(3) the accessed component doesn't know the importance of the user
credentials (the user may have used the same password in several
systems, or the user may have very high privileges in other parts
of this system), increasing the risk involved in (2).

I see no reason to suppose Mailman is not subject to these
considerations.  (3) is certainly relevant, as I know that I am
simultaneously a site owner, a list owner, a moderator, and a
subscriber for some lists.

There is a plausible workflow in which a user (who happens to be a
list owner) who is browsing the archives is given a subscriber-level
token, and when they decide to access a list admin page, they need to
re-authenticate to upgrade their authorization to list owner.  If they
then access a non-admin page, or they time out before accessing
another admin page, the owner-level token is downgraded to a
subscriber token.  (This is like sudo on POSIX systems.)

I'm not arguing that Mailman should default to such a workflow, but I
think we should be able to support it.  Passing around user
credentials makes it harder to audit such a workflow.

  As for security, exposing the authorization server to direct
  Internet access is, in itself, a security weak point.

I wouldn't say necessarily weak, but it certainly expands the attack
surface that needs to be defended.  That's why I don't want to include
an auth server implemented by security amateurs (us!)

___
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

Re: [Mailman-Developers] Architecture for extra profile info

2013-04-19 Thread Stephen J. Turnbull

Barry Warsaw writes:

  It's also probably true that few people actually use the email command
  interface - heck even I rarely use it.

Emacs and (some) Debian folks do, though.  It's not random, there are
whole constituencies (small) out there for this feature.

___
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

Re: [Mailman-Developers] Architecture for extra profile info

2013-04-19 Thread Stephen J. Turnbull

Barry Warsaw writes:

  but also remember how much pain we had at the sprint trying to get Postorius
  and HyperKitty deployed together (how's that coming by the way?).

I got mail from Yarko, does that help? :-)

I hope to get back to that this week, now that I've initialized my
classes.  Dunno if Yarko has done anything, or if anyone else is
working on it.

  Eventually OAuth is a good idea and I'm not aware of anything else
  that fits the bill as well, for authenticated scripting of REST
  APIs.  But we probably don't need it for now.

We don't *need* anything we don't already have :-), but I'd like to
see OAuth and Persona for subscribers.

  One important requirement is that for any data that is kept in both the core
  and the user database, we must have a way of keeping them in sync.  The
  easiest way of doing that I think is to allow two way communication between
  them so that if data changes in the core (e.g. an address gets verified by
  reply instead of link-click), the core can inform the user database of this
  event.

This isn't going to fly for enterprise usage.  I mean, you can inform
the enterprise DB, but it's highly unlikely to do anything useful with
the information.  I think in the core user has to be a rather
abstract class, which provides links to profile information (perhaps
in a Mailman-supplied component, or in an enterprise DB, or both[1]),
and to list-related information.

Footnotes: 
[1]  UI note: if both, enterprises may want official information to
be visually distinguished from unofficial information.
___
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

Re: [Mailman-Developers] Architecture for extra profile info

Hi,

some first thoughts on it:

1) It should be self-contained.
Meaning: It should not depend on any
mailman/mailman.client/postorius/hyperkitty packages.

2) Like the core, it should implement a Python-based webserver.
It doesn't need to run on Ports 80/443, so we don't have to care about
one of the popular web servers already listening to those ports.
Also, we definitely don't want admins to have to follow another how
to setup mailman.users with Apache/mod_wsgi howto.
It should just run if someone says start (Maybe it can even hook
into $ bin/mailman start? I know, that contradicts item 1. ...).

3) It doesn't need Django.
Since it will not deliver any HTML (except an oAuth login form -- see
5.) and it doesn't need to be integrated into any existing web site,
we can choose a more light-weight framework.

4) Adding new content types for user records should be easy, but
clearly defined.
We don't know what information applications need to store. Icons,
essays, avatars, IRC handles, Twiter names, ...
So we might think about using a schema-less database, but: We don't
want to make it possible to just manipulate the result JSON and POST
it back to the resource, possible deleting things other apps need. So
adding new information types should be a separate process.

5) It should implement an oAuth provider.
This could be used for API authenticaion and to log into
Postorius/Hyperkitty (even on other servers. Hint: Reputation!)
We won't need this for a first prototype though. For now we're
probably fine with 6)

6) Like the core it should be accessible with BasicAuth from localhost.
Ideally, in the future, it should be accessible both via BasicAuth
from localhost and via oAuth from the outside world...

Please correct me where I'm being stupid!

Florian





2013/4/18 Terri Oda te...@zone12.com:
 Background for folk new to this discussion:

 Currently, all user information is stored in Mailman core, but it's minimal:
 a real name, a set of email addresses, subscription info, and preferences.
 Barry suggests that it should stay minimal: only the things Mailman needs to
 know to correctly deliver mail (which actually doesn't include real name
 but let's leave that as a legacy item for the moment)

 It's pretty likely that future features of Mailman will want to attach extra
 information to users.  Some of it will be social-y stuff like user icons for
 HyperKitty to display in the archives. Other things include metrics like
 when did this person last post to the list? or how many posts have they
 made over the lifetime of this list?  One thing I know of is that Systers
 requires a short essay for all new subscribers, explaining why they want to
 join the list.   (And they're considering porting this feature to Postorius,
 which means we potentially want an answer to where will the extra profile
 data get stored? before their students start coding.)

 So...

 I think we've sort of agreed that it would be best if whatever we built just
 had a rest interface and hyperkitty/postorius/whatever would talk to it
 through there, and could share data that way, but we need a simple prototype
 that folk (particularly students) will be able to start using, and there's
 still some internal architecture decisions that need to be made.

 Does anyone have time to build such a thing or write up some short
 architectural documents so a student could build such a thing in relatively
 short order?  It doesn't have to be the perfect final design, but we
 probably need a basic starter api for adding, accessing, editing and
 possibly even removing profile data.

 Thoughts?

  Terri


 ___
 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/f%40state-of-mind.de

 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

Re: [Mailman-Developers] Architecture for extra profile info

Main comment: Sounds like LDAP to me.

Florian Fuchs writes:

  5) It should implement an oAuth provider.

I don't see this.  Mailman is an auth consumer.  The only people
Mailman can provide auth for are the site admins.  Everybody else is
more or less untrustworthy.

I can see that there are applications where it would be useful to have
an auth provider bundled with Mailman, but I think implementing it is
somebody else's job.

  This could be used for API authenticaion and to log into
  Postorius/Hyperkitty

I think generic auth provider is overkill for these purposes, and a
trap for anybody who thinks we know enough about crypto/security to do
this stuff well.
___
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

Re: [Mailman-Developers] Architecture for extra profile info

2013/4/18 Stephen J. Turnbull step...@xemacs.org:
 Florian Fuchs writes:

   5) It should implement an oAuth provider.

 I don't see this.  Mailman is an auth consumer.  The only people
 Mailman can provide auth for are the site admins.  Everybody else is
 more or less untrustworthy.

 I can see that there are applications where it would be useful to have
 an auth provider bundled with Mailman, but I think implementing it is
 somebody else's job.

   This could be used for API authenticaion and to log into
   Postorius/Hyperkitty

 I think generic auth provider is overkill for these purposes, and a
 trap for anybody who thinks we know enough about crypto/security to do
 this stuff well.

I agree it's probably not easy. And, yes, maybe we need someone to
help us with that.

But maybe we can take a moment to think about the usefulness of such a
feature and the possibilities this might open up, rather than
dismissing the use of a certain technology right off the bat. If we're
unsure we can implement this in a secure way, we can still say no to
this. Also, who says such a feature would be enabled by default? We
can add it as an experts only thing and leave it up to the admins to
make sure they use it in a secure environment.

I remember several discussions during PyCon(s) and on IRC where
scenarios of different mailman instances talking to each other came
up. Of course that doesn't mean implementing  a generic oAuth provider
is the only answer to this. If there are better and easier solutions,
fine.

Luckily going beyond localhost isn't something we need for the
prototype that Terri suggested to be built for GSoC.

Florian
___
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

Re: [Mailman-Developers] Architecture for extra profile info

Whoa! Perhaps I don't understand oAuth. I thought that oAuth (and persona, 
kerberos, etc.) were protocols whereby one system (the provider) furnishes 
credentials for a second system (the client) to some third system (the 
consumer).

By configuration, the consumer trusts that the provider has verified the 
client's identity and furnished appropriate credentials.
Thus, when the client presents credentials in an interaction with the consumer, 
the consumer provides services on the basis of the credentials.

If we assume that we distribute the MM implementation to include more than the 
two (core and web UI) systems by having, for example, a user manager, there 
might be an argument for passing around such credentials.

However, the design that has been followed thus far does not have the client 
communicating directly with the consumer system. Instead, the web UI interacts 
as an agent for the client. In this model, we have implicitly trusted the agent 
to properly represent the client and also screen client requests in accordance 
with system policy. Thus, although we need some level of authentication of the 
agent, there is no need for third party credentials such as those implemented 
in oAuth.

A connection on localhost is a form of credential. Trusting that the OS 
design restricts access to the connection, and trusting the applications 
running on that host provides a level of identification and trust.

There is no reason why alternate channels cannot be substituted as long as a 
means of identification (such as shared secrets) is utilized.
In those cases, the security of the communication channel and the 
trustworthiness of the agent system need to be considered. However, in a 
logical sense, the interaction is the same as one using the localhost channel.


On Apr 18, 2013, at 4:27 AM, Florian Fuchs flo.fu...@gmail.com wrote:

 2013/4/18 Stephen J. Turnbull step...@xemacs.org:
 Florian Fuchs writes:
 
 5) It should implement an oAuth provider.
 
 I don't see this.  Mailman is an auth consumer.  The only people
 Mailman can provide auth for are the site admins.  Everybody else is
 more or less untrustworthy.
 
 I can see that there are applications where it would be useful to have
 an auth provider bundled with Mailman, but I think implementing it is
 somebody else's job.
 
 This could be used for API authentication and to log into
 Postorius/Hyperkitty
 
 I think generic auth provider is overkill for these purposes, and a
 trap for anybody who thinks we know enough about crypto/security to do
 this stuff well.
 
 I agree it's probably not easy. And, yes, maybe we need someone to
 help us with that.
 
 But maybe we can take a moment to think about the usefulness of such a
 feature and the possibilities this might open up, rather than
 dismissing the use of a certain technology right off the bat. If we're
 unsure we can implement this in a secure way, we can still say no to
 this. Also, who says such a feature would be enabled by default? We
 can add it as an experts only thing and leave it up to the admins to
 make sure they use it in a secure environment.
 
 I remember several discussions during PyCon(s) and on IRC where
 scenarios of different mailman instances talking to each other came
 up. Of course that doesn't mean implementing  a generic oAuth provider
 is the only answer to this. If there are better and easier solutions,
 fine.
 
 Luckily going beyond localhost isn't something we need for the
 prototype that Terri suggested to be built for GSoC.
 
 Florian
 ___
 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/rkw%40dataplex.net
 
 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

Re: [Mailman-Developers] Architecture for extra profile info

On Apr 18, 2013, at 1:19 AM, Florian Fuchs flo.fu...@gmail.com wrote:

 Hi,
 
 some first thoughts on it:
 
 1) It should be self-contained.
 Meaning: It should not depend on any
 mailman/mailman.client/postorius/hyperkitty packages.

Agreed

 2) Like the core, it should implement a Python-based webserver.
 It doesn't need to run on Ports 80/443, so we don't have to care about
 one of the popular web servers already listening to those ports.
 Also, we definitely don't want admins to have to follow another how
 to setup mailman.users with Apache/mod_wsgi howto.
 It should just run if someone says start (Maybe it can even hook
 into $ bin/mailman start? I know, that contradicts item 1. ...).

Where it runs is something that should be easily configurable as a part of 
installation.
To simplify installation, I would advocate that all of the MM subsystem 
interfaces become self-documentating.
By doing so, much of the configuration could be done through a discovery 
mechanism.

That would provide an easy way to have modular plug-in extensions.
It would also provide a way for Postorius to automatically adapt to the 
addition of configuration settings or user fields.

 3) It doesn't need Django.
 Since it will not deliver any HTML (except an oAuth login form -- see
 5.) and it doesn't need to be integrated into any existing web site,
 we can choose a more light-weight framework.

Here I take exception. Dismissing Django is a restriction that unnecessarily 
affects the ease of implementation and, in the common case, complicates the 
integration of the functionality.

Although it could be implemented without Django, it could also be implemented 
as a Django app.
An instance of a django server can then serve the functionality.  As an 
alternative, where appropriate, this app would directly drop in to an 
instance of Postorius or an enterprise website.

One of the advantages of Django is that it can be used as a rapid prototyping 
mechanism. Simplified interfaces to the data are free and more elaborate ones 
can be added in an incremental fashion.
Also, rather than writing custom modules for things such as authentication and 
REST interfaces, there is the large community of third-party extensions which 
readily integrate to provide that functionality.

 4) Adding new content types for user records should be easy, but
 clearly defined.
 We don't know what information applications need to store. Icons,
 essays, avatars, IRC handles, Twiter names, ...
 So we might think about using a schema-less database, but: We don't
 want to make it possible to just manipulate the result JSON and POST
 it back to the resource, possible deleting things other apps need. So
 adding new information types should be a separate process.
 
 5) It should implement an oAuth provider.
 This could be used for API authenticaion and to log into
 Postorius/Hyperkitty (even on other servers. Hint: Reputation!)
 We won't need this for a first prototype though. For now we're
 probably fine with 6)
 
 6) Like the core it should be accessible with BasicAuth from localhost.
 Ideally, in the future, it should be accessible both via BasicAuth
 from localhost and via oAuth from the outside world...
 
 Please correct me where I'm being stupid!
 
 Florian

 2013/4/18 Terri Oda te...@zone12.com:
 Background for folk new to this discussion:
 
 Currently, all user information is stored in Mailman core, but it's minimal:
 a real name, a set of email addresses, subscription info, and preferences.
 Barry suggests that it should stay minimal: only the things Mailman needs to
 know to correctly deliver mail (which actually doesn't include real name
 but let's leave that as a legacy item for the moment)

I would advocate that this User module make it appear as if stores the entire 
record for the user.
In the implementation, it could actually store parts of the user information in 
multiple databases (one of which could be the MM-core).

This would also allow the option of having the MM-core become a client of this 
User module, just as it now relies on an external message store.

 It's pretty likely that future features of Mailman will want to attach extra
 information to users.  Some of it will be social-y stuff like user icons for
 HyperKitty to display in the archives. Other things include metrics like
 when did this person last post to the list? or how many posts have they
 made over the lifetime of this list?  One thing I know of is that Systers
 requires a short essay for all new subscribers, explaining why they want to
 join the list.   (And they're considering porting this feature to Postorius,
 which means we potentially want an answer to where will the extra profile
 data get stored? before their students start coding.)
 
 So...
 
 I think we've sort of agreed that it would be best if whatever we built just
 had a rest interface and hyperkitty/postorius/whatever would talk to it
 through there, and could share data that way, but we need a simple prototype

Re: [Mailman-Developers] Architecture for extra profile info

Florian Fuchs writes:

  But maybe we can take a moment to think about the usefulness of such a
  feature and the possibilities this might open up, rather than
  dismissing the use of a certain technology right off the bat.

I'm not dismissing the use; I'm saying an authentication provider is
out of scope for Mailman, for several reasons.

An auth client is something we clearly need.  The mail auth we use
(plain text passwords) is clearly weak, and we need to improve that.
Web auth is probably OK for most sites if we use HTTP Basic Auth over
HTTPS.  OAuth (or social auth or Persona) is clearly a major
convenience for users, and probably significantly increases security
all by itself (no need for Post-Its with the Mailman password you
almost never use on your monitor bezel).  Both HTTPS+BasicAuth and
OAuth have the advantage that Mailman can delegate the handling of
transmission of secrets over the Internet to professions.  Given that
HTTPS+BasicAuth is probably good enough for most of our users, and
most of the rest will want to use Google/Yahoo/whatever rather than
YAP, where's the need for a provider?

And I *am* thinking about the possibilities implementing a provider
opens up.  Namely, the possibility that we'll distribute buggy code.
:-P

  I remember several discussions during PyCon(s) and on IRC where
  scenarios of different mailman instances talking to each other came
  up. Of course that doesn't mean implementing  a generic oAuth provider
  is the only answer to this. If there are better and easier solutions,
  fine.

The OAuth2 protocol spec (RFC 6749) makes obscure reference to scope
and tokens acceptable to multiple resource servers.  But I don't think
sharing authorizations is something that a provider deals with.
___
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

Re: [Mailman-Developers] Architecture for extra profile info

2013-04-18 Thread Terri Oda


On 13-04-18 8:03 AM, Richard Wackerbarth wrote:

On Apr 18, 2013, at 1:19 AM, Florian Fuchs flo.fu...@gmail.com wrote:


1) It should be self-contained.
Meaning: It should not depend on any
mailman/mailman.client/postorius/hyperkitty packages.

Agreed


I agree about not needing postorious/hyperkitty, but I think a case 
could be made that interdependence with mailman core and mailman client 
might make sense.

I would advocate that this User module make it appear as if stores the entire 
record for the user.
In the implementation, it could actually store parts of the user information in 
multiple databases (one of which could be the MM-core).

This would also allow the option of having the MM-core become a client of this 
User module, just as it now relies on an external message store.


Two options occur to me:

1. The user module is what mm-core uses for all user stuff.

I thinks case, case we have to be *much* more conservative about 
dependencies.  I think Django would be right out as a dependency for 
Mailman core, for example.  Plus, we're going to have to care a lot more 
about speed and all.


2. The user module reads from mm-core and augments it.

This gives us the ability to supplement mm-core without impeding speed.  
We discussed possibly filling in the blanks with respect to things like 
the user preferences (which are currently set by membership, by user and 
by email address... but a lot of those return an empty set when queried 
if nothing is set directly there...) so this is maybe something we 
already want.


Conceptually, #1 is probably easier because everything will be in one 
place, but if we do #2 right, we can make it just as conceptually easy 
for HyperKitty/Postorius/etc. without impeding Barry's core dev at all.  
That does mean in case 2 that Mailman Extraneous User Stuff is going to 
depend on Mailman Core, though.


My preference is #2:
a) It doesn't add any dependencies to Mailman core.
b) It doesn't require big changes in Mailman Core.  Given that core is 
pretty much ready to release, now would be a bad time for changes, and 
I'm just not sure we can justify that amount of work for the types of 
features that will be built on the extraneous user stuff.
c) It will be much easier to rip this out and replace it when we better 
understand our actual needs.   (e.g. Right now, I think a case could be 
made that a quick mock-up in django would be fine, but I suspect that 
requiring django for some potential applications would border on ridiculous)


We're probably going to be running around with a bit of a hack job for 
the user database in the near future (either done by a student who needs 
it in a hurry or done by one of the core devs to support a student who 
needs it in a hurry) so while I don't like to design on the assumption 
it's going to go wrong, I think in this case planning for a redesign 
might be prudent because it's pretty clear we don't actually know all 
our requirements.


 Terri

___
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

Re: [Mailman-Developers] Architecture for extra profile info

Richard Wackerbarth writes:

  Whoa! Perhaps I don't understand oAuth. I thought that oAuth (and
  persona, kerberos, etc.) were protocols whereby one system (the
  provider) furnishes credentials for a second system (the client) to
  some third system (the consumer).

That's correct.

  If we assume that we distribute the MM implementation to include
  more than the two (core and web UI) systems by having, for example,
  a user manager, there might be an argument for passing around such
  credentials.

But the does provide a user manager, and the extra profile info is
in fact intended to be a user manager external to the core.

  Thus, although we need some level of authentication of the agent,
  there is no need for third party credentials such as those
  implemented in oAuth.

The point is that in many cases we would like to dispense with the
agent authentication process altogether, and let a third party manage
that.  This is perfectly acceptable in the case of open subscription
lists where we simply want to ensure that only the subscriber can
change their subscriptions.  For example, a person subscribing a Gmail
account to use that account's credentials rather than creating new
owns inside of Mailman -- which we trust only because the person
demonstrates in a roundabout way that they can access that mailbox.
OAuth allows us to make that check directly in real time.

I suppose that what Florian is thinking is that some owners want
*closed* subscription processes, and therefore want to control the
authentication process themselves.  I agree that that is a valid and
likely (if unusual) use case.  I just think it's better for such users
to go find a provider implementation themselves, rather than offer
them something that I know *I* can't properly design or review, and
haven't seen credentials from anyone else on the team that they can do
it, either.

  There is no reason why alternate channels [to a connection from
  localhost authorized by the OS] cannot be substituted as long as a
  means of identification (such as shared secrets) is utilized.

Sure, but didn't you notice the elephant in the room as you swept it
under the rug?  The implementation of alternate channels matters *a
lot*, and it's not trivial.
___
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

Re: [Mailman-Developers] Architecture for extra profile info

On Apr 18, 2013, at 11:42 AM, Stephen J. Turnbull step...@xemacs.org wrote:

 Richard Wackerbarth writes:

 There is no reason why alternate channels [to a connection from
 localhost authorized by the OS] cannot be substituted as long as a
 means of identification (such as shared secrets) is utilized.
 
 Sure, but didn't you notice the elephant in the room as you swept it
 under the rug?  The implementation of alternate channels matters *a
 lot*, and it's not trivial.

Just because something is important or non-trivial to implement properly does 
not imply that it is difficult for us to utilize it.
Rather than developing our own, we can, and should, leverage the efforts of 
the professionals and use the tools that they provide (such as https and 
oAuth, etc.).

Certainly, the proper administration of each, and every, host is an essential 
element to prevent access on the coat tails of the trusted agents. But that 
also applies to the localhost implementation.

___
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

Re: [Mailman-Developers] Architecture for extra profile info

Richard Wackerbarth writes:
  On Apr 18, 2013, at 11:42 AM, Stephen J. Turnbull step...@xemacs.org 
  wrote:
  
   Richard Wackerbarth writes:
  
   There is no reason why alternate channels [to a connection from
   localhost authorized by the OS] cannot be substituted as long as a
   means of identification (such as shared secrets) is utilized.
   
   Sure, but didn't you notice the elephant in the room as you swept it
   under the rug?  The implementation of alternate channels matters *a
   lot*, and it's not trivial.
  
  Just because something is important or non-trivial to implement
  properly does not imply that it is difficult for us to utilize it.
  Rather than developing our own, we can, and should, leverage the
  efforts of the professionals and use the tools that they provide
  (such as https and oAuth, etc.).
  
  Certainly, the proper administration of each, and every, host is an
  essential element to prevent access on the coat tails of the
  trusted agents. But that also applies to the localhost
  implementation.

I don't understand what you're advocating, your comments are way too
general.

My position is that secure authentication and authorization is a hard
problem, and we should avoid doing that as much as possible (partly
because as far as I know none of us are experts).  No channels that
few sites will use, ditto OAuth providers.  Concentrate on a couple of
channels with specific, well-understood, universal (or at least very
common) use cases.

The channels I have in mind are (1) shell access, (2) Basic Auth over
HTTPS for people who need to control access fairly tightly, and (3)
OAuth and/or Persona clients allowing authentication by any of a
number of public providers for user (especially subscriber)
convenience.  I'm not wedded to any of those (except (1), for obvious
reasons), but I don't think it's a good idea to extend the list if we
can avoid it.
___
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

Re: [Mailman-Developers] Architecture for extra profile info


On Apr 18, 2013, at 11:42 AM, Stephen J. Turnbull step...@xemacs.org wrote:

 Richard Wackerbarth writes:
 
 Whoa! Perhaps I don't understand oAuth. I thought that oAuth (and
 persona, kerberos, etc.) were protocols whereby one system (the
 provider) furnishes credentials for a second system (the client) to
 some third system (the consumer).
 
 That's correct.
 
 If we assume that we distribute the MM implementation to include
 more than the two (core and web UI) systems by having, for example,
 a user manager, there might be an argument for passing around such
 credentials.
 
 But the does provide a user manager, and the extra profile info is
 in fact intended to be a user manager external to the core.
 
 Thus, although we need some level of authentication of the agent,
 there is no need for third party credentials such as those
 implemented in oAuth.
 
 The point is that in many cases we would like to dispense with the
 agent authentication process altogether, and let a third party manage
 that.  This is perfectly acceptable in the case of open subscription
 lists where we simply want to ensure that only the subscriber can
 change their subscriptions.  For example, a person subscribing a Gmail
 account to use that account's credentials rather than creating new
 owns inside of Mailman -- which we trust only because the person
 demonstrates in a roundabout way that they can access that mailbox.
 OAuth allows us to make that check directly in real time.

I have no problem with, and actually encourage, that we act as a consumer of 
oAuth credentials.
However, the issue here is whether we should be provider of oAuth credentials 
(which might then be presented to some outside, totally unrelated, entity.

___
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

Re: [Mailman-Developers] Architecture for extra profile info


On Apr 18, 2013, at 12:21 PM, Stephen J. Turnbull step...@xemacs.org wrote:

 Richard Wackerbarth writes:
 On Apr 18, 2013, at 11:42 AM, Stephen J. Turnbull step...@xemacs.org 
 wrote:
 
 Richard Wackerbarth writes:
 
 There is no reason why alternate channels [to a connection from
 localhost authorized by the OS] cannot be substituted as long as a
 means of identification (such as shared secrets) is utilized.
 
 Sure, but didn't you notice the elephant in the room as you swept it
 under the rug?  The implementation of alternate channels matters *a
 lot*, and it's not trivial.
 
 Just because something is important or non-trivial to implement
 properly does not imply that it is difficult for us to utilize it.
 Rather than developing our own, we can, and should, leverage the
 efforts of the professionals and use the tools that they provide
 (such as https and oAuth, etc.).
 
 Certainly, the proper administration of each, and every, host is an
 essential element to prevent access on the coat tails of the
 trusted agents. But that also applies to the localhost
 implementation.
 
 I don't understand what you're advocating, your comments are way too
 general.
 
 My position is that secure authentication and authorization is a hard
 problem, and we should avoid doing that as much as possible (partly
 because as far as I know none of us are experts).  No channels that
 few sites will use, ditto OAuth providers.  Concentrate on a couple of
 channels with specific, well-understood, universal (or at least very
 common) use cases.
 
 The channels I have in mind are (1) shell access, (2) Basic Auth over
 HTTPS for people who need to control access fairly tightly, and (3)
 OAuth and/or Persona clients allowing authentication by any of a
 number of public providers for user (especially subscriber)
 convenience.  I'm not wedded to any of those (except (1), for obvious
 reasons), but I don't think it's a good idea to extend the list if we
 can avoid it.

Perhaps I didn't understand you.  I thought that you were advocating the 
omission of any channels other than shell and localhost.
I was trying to point out that HTTPS, oAuth, etc. should be equally viable (and 
they don't REQUIRE that the components reside on the shame host).
___
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

Re: [Mailman-Developers] Architecture for extra profile info


On Apr 18, 2013, at 11:26 AM, Terri Oda te...@zone12.com wrote:

 On 13-04-18 8:03 AM, Richard Wackerbarth wrote:
 On Apr 18, 2013, at 1:19 AM, Florian Fuchs flo.fu...@gmail.com wrote:
 
 1) It should be self-contained.
 Meaning: It should not depend on any
 mailman/mailman.client/postorius/hyperkitty packages.
 Agreed
 
 I agree about not needing postorious/hyperkitty, but I think a case could be 
 made that interdependence with mailman core and mailman client might make 
 sense.

Clearly, if you are going to follow (2) below, you will need to interface to 
MM-core for the portion that is stored there.

 I would advocate that this User module make it appear as if stores the 
 entire record for the user.
 In the implementation, it could actually store parts of the user information 
 in multiple databases (one of which could be the MM-core).
 
 This would also allow the option of having the MM-core become a client of 
 this User module, just as it now relies on an external message store.

Notice that I indicate that this is an option.  Although, in the long run, I 
think it is the right way to go, getting there can be a migration and not 
something that needs to happen all at once.
 
 Two options occur to me:
 
 1. The user module is what mm-core uses for all user stuff.
 
 I thinks case, case we have to be *much* more conservative about 
 dependencies.  I think Django would be right out as a dependency for Mailman 
 core, for example.

I thought that we were viewing this as a service accessed through a REST 
interface. MM core need never know if it is implemented using Django or FORTRAN 
or ...

Why is depending on some part of Django prohibited when core uses zope, storm, 
... ?
Dependencies are just dependencies. As long as they are stable and readily 
available, why not use those that are useful?

  Plus, we're going to have to care a lot more about speed and all.

Much of the user information is not needed in the message handler (where speed 
is a consideration).

Functions such as administration-by-mail that need to access the information 
are much less critical.
Further, I will argue that those functions should be factored out of the core 
and exist as separate components.

 2. The user module reads from mm-core and augments it.
 
 This gives us the ability to supplement mm-core without impeding speed.  We 
 discussed possibly filling in the blanks with respect to things like the user 
 preferences (which are currently set by membership, by user and by email 
 address... but a lot of those return an empty set when queried if nothing is 
 set directly there...) so this is maybe something we already want.
 
 Conceptually, #1 is probably easier because everything will be in one place, 
 but if we do #2 right, we can make it just as conceptually easy for 
 HyperKitty/Postorius/etc. without impeding Barry's core dev at all.  That 
 does mean in case 2 that Mailman Extraneous User Stuff is going to depend on 
 Mailman Core, though.
 
 My preference is #2:

I would agree except to the extent that Postorius references the user 
information.
I believe that all user data should be accessed from the same source. I 
consider it poor design for the consumer of data to have to keep track of where 
particular parts of the data are stored.

 a) It doesn't add any dependencies to Mailman core.
 b) It doesn't require big changes in Mailman Core.  Given that core is pretty 
 much ready to release, now would be a bad time for changes, and I'm just not 
 sure we can justify that amount of work for the types of features that will 
 be built on the extraneous user stuff.
 c) It will be much easier to rip this out and replace it when we better 
 understand our actual needs.   (e.g. Right now, I think a case could be made 
 that a quick mock-up in django would be fine, but I suspect that requiring 
 django for some potential applications would border on ridiculous)
 
 We're probably going to be running around with a bit of a hack job for the 
 user database in the near future (either done by a student who needs it in a 
 hurry or done by one of the core devs to support a student who needs it in a 
 hurry) so while I don't like to design on the assumption it's going to go 
 wrong, I think in this case planning for a redesign might be prudent because 
 it's pretty clear we don't actually know all our requirements.
 
 Terri
___
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

Re: [Mailman-Developers] Architecture for extra profile info

2013/4/18 Richard Wackerbarth rich...@nfsnet.org:
 On Apr 18, 2013, at 1:19 AM, Florian Fuchs flo.fu...@gmail.com wrote:
 3) It doesn't need Django.
 Since it will not deliver any HTML (except an oAuth login form -- see
 5.) and it doesn't need to be integrated into any existing web site,
 we can choose a more light-weight framework.

 Here I take exception. Dismissing Django is a restriction that unnecessarily 
 affects the ease of implementation and, in the common case, complicates the 
 integration of the functionality.

 Although it could be implemented without Django, it could also be implemented 
 as a Django app.
 An instance of a django server can then serve the functionality.  As an 
 alternative, where appropriate, this app would directly drop in to an 
 instance of Postorius or an enterprise website.

 One of the advantages of Django is that it can be used as a rapid prototyping 
 mechanism. Simplified interfaces to the data are free and more elaborate 
 ones can be added in an incremental fashion.
 Also, rather than writing custom modules for things such as authentication 
 and REST interfaces, there is the large community of third-party extensions 
 which readily integrate to provide that functionality.

It's not that I don't want to use Django. I just wanted to point out
that we won't need much of it for a pure JSON API. OTOH adding a new
dependency by using another framework is probably not a good idea
either. So if we want to keep the number of dependencies low, the
alternative would probably be to use no framework at all and use
restish for the, well, REST stuff (or whatever library the core will
be using in the future).

Florian

 I would advocate that this User module make it appear as if stores the 
 entire record for the user.
 In the implementation, it could actually store parts of the user information 
 in multiple databases (one of which could be the MM-core).

+1
___
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

Re: [Mailman-Developers] Architecture for extra profile info

2013-04-18 Thread Terri Oda


On 13-04-18 2:28 AM, Stephen J. Turnbull wrote:

Main comment: Sounds like LDAP to me.
Actually, this is a really important comment.  I was sort of wondering 
that too when I started writing the description.  LDAP is a moderately 
frequently requested feature already.  Would it make sense to use that 
probably rather than rest, or make a rest framework that talked to ldap 
under the hood?


 Terri

___
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

Re: [Mailman-Developers] Architecture for extra profile info

2013/4/18 Terri Oda te...@zone12.com:
 We're probably going to be running around with a bit of a hack job for the
 user database in the near future (either done by a student who needs it in a
 hurry or done by one of the core devs to support a student who needs it in a
 hurry) so while I don't like to design on the assumption it's going to go
 wrong, I think in this case planning for a redesign might be prudent because
 it's pretty clear we don't actually know all our requirements.

I think in this case it makes sense to spend a more time on the API as
seen from the outside (urls, methods, json responses) than the actual
implementation. If the API is good, it's totally acceptable if the
underlying implementation will be redesigned later.

Florian
___
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

Re: [Mailman-Developers] Architecture for extra profile info


On Apr 18, 2013, at 2:39 PM, Florian Fuchs flo.fu...@gmail.com wrote:

 2013/4/18 Terri Oda te...@zone12.com:
 We're probably going to be running around with a bit of a hack job for the
 user database in the near future (either done by a student who needs it in a
 hurry or done by one of the core devs to support a student who needs it in a
 hurry) so while I don't like to design on the assumption it's going to go
 wrong, I think in this case planning for a redesign might be prudent because
 it's pretty clear we don't actually know all our requirements.
 
 I think in this case it makes sense to spend a more time on the API as
 seen from the outside (urls, methods, json responses) than the actual
 implementation. If the API is good, it's totally acceptable if the
 underlying implementation will be redesigned later.

I agree and I would advocate that that API model be based on the interface that 
you can readily get from
a django database model and the django-rest-framework.

There is a big advantage to being able to readily edit the model and have the 
corresponding changes to the interface automatically generated. Since HK and 
Postorius already use Django, you are not adding any significant dependancies. 
And you can leverage a existing code base for the implementation details.

___
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

Re: [Mailman-Developers] Architecture for extra profile info

Yes, yes. Please re-invent the wheel once again.

And while you are at it, you might just remove the dependancies on zope and 
storm, etc.

I think that you are missing the point that, at this time, this is intended to 
provide the capabilities that MM-core chooses not to implement.
Those website components (HK and Postorius) are being driven by Django and you 
only make it more difficult to implement them when choose a different schema to 
model/present the data.

On Apr 18, 2013, at 2:29 PM, Florian Fuchs flo.fu...@gmail.com wrote:

 2013/4/18 Richard Wackerbarth rich...@nfsnet.org:
 On Apr 18, 2013, at 1:19 AM, Florian Fuchs flo.fu...@gmail.com wrote:
 3) It doesn't need Django.
 Since it will not deliver any HTML (except an oAuth login form -- see
 5.) and it doesn't need to be integrated into any existing web site,
 we can choose a more light-weight framework.
 
 Here I take exception. Dismissing Django is a restriction that unnecessarily 
 affects the ease of implementation and, in the common case, complicates the 
 integration of the functionality.
 
 Although it could be implemented without Django, it could also be 
 implemented as a Django app.
 An instance of a django server can then serve the functionality.  As an 
 alternative, where appropriate, this app would directly drop in to an 
 instance of Postorius or an enterprise website.
 
 One of the advantages of Django is that it can be used as a rapid 
 prototyping mechanism. Simplified interfaces to the data are free and more 
 elaborate ones can be added in an incremental fashion.
 Also, rather than writing custom modules for things such as authentication 
 and REST interfaces, there is the large community of third-party extensions 
 which readily integrate to provide that functionality.
 
 It's not that I don't want to use Django. I just wanted to point out
 that we won't need much of it for a pure JSON API. OTOH adding a new
 dependency by using another framework is probably not a good idea
 either. So if we want to keep the number of dependencies low, the
 alternative would probably be to use no framework at all and use
 restish for the, well, REST stuff (or whatever library the core will
 be using in the future).
 
 Florian
 
 I would advocate that this User module make it appear as if stores the 
 entire record for the user.
 In the implementation, it could actually store parts of the user information 
 in multiple databases (one of which could be the MM-core).
 
 +1

___
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

Re: [Mailman-Developers] Architecture for extra profile info


On Apr 18, 2013, at 1:54 PM, Florian Fuchs flo.fu...@gmail.com wrote:

 2013/4/18 Richard Wackerbarth r...@dataplex.net:
 Whoa! Perhaps I don't understand oAuth. I thought that oAuth (and persona, 
 kerberos, etc.) were protocols whereby one system (the provider) furnishes 
 credentials for a second system (the client) to some third system (the 
 consumer).
 
 By configuration, the consumer trusts that the provider has verified the 
 client's identity and furnished appropriate credentials.
 Thus, when the client presents credentials in an interaction with the 
 consumer, the consumer provides services on the basis of the credentials.
 
 If we assume that we distribute the MM implementation to include more than 
 the two (core and web UI) systems by having, for example, a user manager, 
 there might be an argument for passing around such credentials.
 
 I was primarily thinking about the (future) authenticated REST API in
 Postorius. In that scenario a third party web app that we don't know
 would request an access token from the user profile store (provider)
 as well a user's email address. It would then use that access token
 for requests to the Postorius API (consumer).
 
 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.
 
 or
 
 2) use some other authentication method.
 
 
 1) is odd in my opinion. Mailman is free software. And there are not
 too many oauth providers that match that philosophy.
 2) would be totally great if we found something that doesn't require a
 user to provide his credentials to said 3rd party app.

Look at what happens now.  The user contacts Postorius and presents either some 
oAuth/BrowserID-style credential or it presents a username/password. In 
exchange, Postorius issues a local credential (session key).

When the username/password path is chosen, Postorius acts as an agent for the 
user and verifies the login. In this case, Postorius must see the underlying 
credential (username/password pair) to be able to present it to the 
authenticator.  In the oAuth path, Postorius never sees the underlying 
credential, but exchanges the presented one for its local credential.

Since we consider the user manager to be a part of the MM complex, what have we 
gained by hiding the underlying credential from the web interface?

Therefore, I would suggest that we need to be able to accept third-party 
(oAuth) credentials and also locally presented ones.
I don't see where we gain an advantage by exposing the authenticator as a 
separate oAuth provider.


 I don't know. Maybe I'm missing something. And of course I agree with
 Stephen: If it's too hairy in terms of security, we should not do it.
 
 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... ?).
 
 Florian

___
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

Re: [Mailman-Developers] Architecture for extra profile info

2013/4/18 Richard Wackerbarth r...@dataplex.net:
 Yes, yes. Please re-invent the wheel once again.

 And while you are at it, you might just remove the dependancies on zope and 
 storm, etc.

 I think that you are missing the point that, at this time, this is intended 
 to provide the capabilities that MM-core chooses not to implement.
 Those website components (HK and Postorius) are being driven by Django and 
 you only make it more difficult to implement them when choose a different 
 schema to model/present the data.

I don't want to re-invent the wheel and I don't advocate dismissing
Django. Django is probably perfect for the prototype. It might also be
perfect for the final thing. But we don't know what database we're
gonna use in the end (which determines if the Django ORM still fits),
or if we'll use many HTML templates etc. If we end up not using many
of the things that make Django great, we might wanna think about if we
want to use it. And might still come to the conclusion that we do. All
I'm saying is: The environment for such an app could be a little
different to Postorius/HK, so let's spend some thought on it. Is this
such a bad idea?

Florian
___
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

Re: [Mailman-Developers] Architecture for extra profile info

What I am suggesting is that we use the JSON format and URLs that are generated 
by this combination.
If you later decide to implement it in a different framework, you can still use 
the same external representation.

On Apr 18, 2013, at 4:33 PM, Florian Fuchs flo.fu...@gmail.com wrote:

 2013/4/18 Richard Wackerbarth r...@dataplex.net:
 Yes, yes. Please re-invent the wheel once again.
 
 And while you are at it, you might just remove the dependancies on zope and 
 storm, etc.
 
 I think that you are missing the point that, at this time, this is intended 
 to provide the capabilities that MM-core chooses not to implement.
 Those website components (HK and Postorius) are being driven by Django and 
 you only make it more difficult to implement them when choose a different 
 schema to model/present the data.
 
 I don't want to re-invent the wheel and I don't advocate dismissing
 Django. Django is probably perfect for the prototype. It might also be
 perfect for the final thing. But we don't know what database we're
 gonna use in the end (which determines if the Django ORM still fits),
 or if we'll use many HTML templates etc. If we end up not using many
 of the things that make Django great, we might wanna think about if we
 want to use it. And might still come to the conclusion that we do. All
 I'm saying is: The environment for such an app could be a little
 different to Postorius/HK, so let's spend some thought on it. Is this
 such a bad idea?
 
 Florian

___
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

Re: [Mailman-Developers] Architecture for extra profile info

Richard Wackerbarth writes:

  Perhaps I didn't understand you.  I thought that you were
  advocating the omission of any channels other than shell and
  localhost.

I'm saying that we should make appropriate Mailman components be OAuth
clients (subject to site policy, per component), but try to avoid
providing *any* authentication ourselves (localhost relies on existing
shell access mechanisms via OS or SSH etc, HTTP Basic auth relies on
Apache or other webserver, OAuth we'll have to build in, but the
actual authentication is done by 3rd party providers).  I suppose
we'll have to provide moderation-by-password-in-headers and the
traditional triple-handshake-by-mail for backward compatibility.

Ah - I missed a very important channel: secure mail via OpenPGP.  We
need something like that (but again, the actual auth/auth process is
done by GPG or PGP, we just rely on the token (signature) provided as
a valid identification of a user).

  I was trying to point out that HTTPS, oAuth, etc. should be equally
  viable (and they don't REQUIRE that the components reside on the
  shame host).

I don't think anybody is opposed to exploring distributed
architecture, and that implies securing inter-component
communications.  The question is how much of the security architecture
we should provide ourselves.  I advocate restricting that to the bare
minimum, by which I mean we don't *do* anything we don't *need* to do
ourselves, not we don't reimplement functionality that is available
in Python packages or 3rd-party libraries we can wrap.



___
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

Re: [Mailman-Developers] Architecture for extra profile info

Richard Wackerbarth writes:

  I have no problem with, and actually encourage, that we act as a
  consumer of oAuth credentials.

+1

  However, the issue here is whether we should be provider of oAuth
  credentials (which might then be presented to some outside, totally
  unrelated, entity.

-1

___
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

Re: [Mailman-Developers] Architecture for extra profile info

2013-04-18 Thread Barry Warsaw

Terri, thanks for kicking off this discussion!

On Apr 18, 2013, at 01:34 PM, Terri Oda wrote:

On 13-04-18 2:28 AM, Stephen J. Turnbull wrote:
 Main comment: Sounds like LDAP to me.

Actually, this is a really important comment.  I was sort of wondering that
too when I started writing the description.  LDAP is a moderately frequently
requested feature already.  Would it make sense to use that probably rather
than rest, or make a rest framework that talked to ldap under the hood?

I agree that this is a really interesting suggestion.

What's interesting to me about it is that this acknowledges that
administrative control of this extra user information may fall to folks not at
all directly involved in mailing list administration.

You can imagine that a company would already have their LDAP database of
additional user information, from postal addresses, to phone numbers, to IRC
handles, pictures and icons, birthdays, etc.  Further, I can imagine that if
that company were to be running MM3 and HyperKitty, they'd probably not want
to duplicate that information in multiple databases, they'd just want to pull
the pictures and IRC nicks out of LDAP.  For their purposes, their LDAP
database *is* their user database.

Of course, some of that information may also be used in part or in whole for
the core, e.g. display names (which actually are useful in places, such as
crafting the From header for a virgin notification).

Now, at least conceptually, I've always thought about the user database as one
of the three pillars of information in the core, the other two being the list
database and the message store.  This is why for example subscriptions do not
just link a foreign key for the mlist to a foreign key to the address, because
this would not allow for separation of these two pillars[1].

Furthermore, the use of interfaces internally is meant to allow for
alternative implementations of the lowest database layer of these pillars,
without affecting any functionality above it.  So let's say even in the core,
user passwords, display names, and preferences were kept in LDAP.  An
alternative implementation of user.py would pull the data in from there and as
long as it satisfied the syntactic and semantic APIs of the IUser interface,
everything else in MM3 would continue to work.

You could extend this to the idea expressed elsewhere that the core could use
this external user database.  Why not?  The external user database could be
accessible over REST or a via a database server, etc.  We'd need an
implementation of the underlying data objects that could talk to this user
database and satisfy the interfaces, and that should be all you'd need.
Making it performant enough for the core is just an engineering exercise
wink.

-Barry

[1] Whether any of this works or has the right separation is another matter
entirely. ;)  For example, looking at it now, I'm not so sure Members
shouldn't be part of the MailingList pillar rather than the user database
pillar.
___
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

Re: [Mailman-Developers] Architecture for extra profile info

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.

___
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

Re: [Mailman-Developers] Architecture for extra profile info

Richard Wackerbarth writes:

  Since we consider the user manager to be a part of the MM complex,
  what have we gained by hiding the underlying credential from the
  web interface?

Security.  See the OAuth 2.0 spec (RFC 6749) which recommends (at
SHOULD level) this practice.

___
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

Re: [Mailman-Developers] Architecture for extra profile info

Barry Warsaw writes:

  What's interesting to me about it is that this acknowledges that
  administrative control of this extra user information may fall to
  folks not at all directly involved in mailing list administration.

I think this is crucial to World Domination^W^WMailman 3 uptake.

  Now, at least conceptually, I've always thought about the user
  database as one of the three pillars of information in the core,
  the other two being the list database and the message store.

I like this conceptual division, but I admit I haven't thought too
carefully about what goes where (eg, you mention Members).
___
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

Re: [Mailman-Developers] Architecture for extra profile info