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
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" <stephen@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
I would like to remind/tell you all that FOR THIS RELEASE, we will ONLY be supporting Mozilla Persona and passwords as authentication methods. This is not up for discussion at this time; it's a choice we've made to in order to help move the release forwards.
As such, any discussion of enterprise use of google or twitter or what have you is pretty much academic. I am satisfied if our authentication plan for methods other than Persona and passwords is "And then the magical python gnomes associate an external account with an internal mailman account!" (I'm not being entirely facetious here; libraries such as django-social-auth are likely to make this sufficiently trivial that it might as well be gnomes.)
While I agree that thinking about these things in advance is useful, I think this discussion is starting to crowd out discussions of time-sensitive things like students' GSoC applications and architectural choices that directly impact how they write said applications.
Let's be realistic: No one is going to plumb everything carefully through with good architectural work in time for it to be useful to GSoC students starting in a few weeks.
So... can we please backburner parts of this discussion until after GSoC so that we don't make it impossible for anyone to start on any project involving extra profile info? I don't want to bog down a student with the need to make this choice and work with these decisions at this stage.
For the purposes of GSoC this summer:
Authentication for the purposes of the extra profile info data store will be provided by either Persona through the web interface or passwords. Yes, even internally for the REST interface: passwords+localhost are good enough for Mailman Core right now, so it's good enough for anything else we do short-term.
We can re-open the floor to better ideas either after GSoC, after the Mailman suite releases, or if Barry vetoes my decision. ;)
Terri
On 13-04-28 10:24 PM, Richard Wackerbarth wrote:
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" <stephen@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/terri%40zone12.com
Security Policy: http://wiki.list.org/x/QIA9
On Apr 29, 2013, at 3:06 PM, Terri Oda <terri@zone12.com> wrote:
- I would like to remind/tell you all that FOR THIS RELEASE, we will ONLY be supporting Mozilla Persona and passwords as authentication methods. This is not up for discussion at this time; it's a choice we've made to in order to help move the release forwards.
That doesn't bother me as long as we recognize that the list of acceptable methods be extensible. In other words, adding a new method would require only the addition of the necessary handlers, forms, etc. and NOT require the re-engineering of the code that handles BrowserID or username/password.
- As such, any discussion of enterprise use of google or twitter or what have you is pretty much academic. I am satisfied if our authentication plan for methods other than Persona and passwords is "And then the magical python gnomes associate an external account with an internal mailman account!" (I'm not being entirely facetious here; libraries such as django-social-auth are likely to make this sufficiently trivial that it might as well be gnomes.)
Agreed.
Authentication for the purposes of the extra profile info data store will be provided by either Persona through the web interface or passwords. Yes, even internally for the REST interface: passwords+localhost are good enough for Mailman Core right now, so it's good enough for anything else we do short-term.
I'll go further than that and suggest, for the purpose of GSoC:
The USER module will be implemented as a Django 1.5 app.
In addition to a custom user model (https://docs.djangoproject.com/en/dev/topics/auth/customizing/#auth-custom-u...), it will provide a Credential verification service. The service will store the associations between users and the parameters used to identify them -- protocol, identifier, confirmation. If the credentials match, the service will return a user_identifier which will be used to access additional information about the user.
The user_identifier will be of a form chosen by the USER module. Other modules (such as MM-core) may associate alternate identifiers (in their namespace) and set or retrieve them. When installed as a part of a MM system, at the installer's discretion, additional user profile information may also be added.
Both the User information and the Credential service will be exposed on a RESTful interface.
This Django app may be installed as a part of a Postorius interface or run as a standalone service.
In the future alternate implementations might be considered, but this will do for now.
It also has the advantage that multiple students can work on things affecting the user record without the other student's work becoming a stopping point to their progress. Then, as they get them working, they can be merged into the postorius system.
On 13-04-29 3:25 PM, Richard Wackerbarth wrote:
I'll go further than that and suggest, for the purpose of GSoC: [snip details]
These are good if you're going to do the implementation. If you're not, I'm happy to leave some of these details up to the person who actually writes the code.
Terri
Terri Oda writes:
- I would like to remind/tell you all that FOR THIS RELEASE, we will ONLY be supporting Mozilla Persona and passwords as authentication methods.
- While I agree that thinking about these things in advance is useful, I think this discussion is starting to crowd out discussions of time-sensitive things like students' GSoC applications and architectural choices that directly impact how they write said applications.
Hold on! Who's "we" and what is being released? There are at least 3 more or less separate projects here (Mailman core, Postorius, and HyperKitty). For login of the webapps Postorius and HyperKitty, I certainly agree that aiming releasing them simultaneously with core 3.0, focusing on a particular authn mechanism (and given work done at the sprints, it should be Persona) is appropriate.
But Mailman 3.0 is *not* the only item on the agenda here. We have a pile of GSoC students who want to implement various forms of authn for Mailman core functionality (secure lists) and some REST API (not clear to me which subproject these adhere to, the core Mailman REST API or a new one to be provided by Postorius). AFAICT, *Persona is not appropriate* for these use cases, as it implies interactive use of a full-featured web browser.
Are you saying that (despite our ideas page) these proposals are a priori nearly unacceptable? It's also rather late in the process to change the rules on the students: if experience is any guide, Melange availability is going to start deteriorating soon.
So... can we please backburner parts of this discussion until after GSoC so that we don't make it impossible for anyone to start on any project involving extra profile info? I don't want to bog down a student with the need to make this choice and work with these decisions at this stage.
Actually, there aren't any students explicitly discussing extra profile information in their proposals. They talk airily about "extended REST API" or similarly generic terms. None talk about storage or representation of profile information. (OK, it was 3am, my memory is fallible. I don't remember any, though.)
For the purposes of GSoC this summer:
Authentication for the purposes of the extra profile info data store will be provided by either Persona through the web interface or passwords.
OK.
Yes, even internally for the REST interface: passwords+localhost are good enough for Mailman Core right now, so it's good enough for anything else we do short-term.
That's going to strongly bias decision-making against at least one REST API proposal, which was made in good faith.
It also formally seems to rule out the secure lists proposal, which obviously depends on an off-line non-localhost authn protocol (based on OpenPGP or S/MIME). Is that your intention?
Regards,
Steve,
Again, we agree. (Something must be wrong :) ) I think that it is important that "we" (the senior developers and mentors) assure that we maintain a structure whereby each of the student proposals can proceed at the same time.
Thus, for example, someone working on the User interface can do so without requiring the "secure" mail features. At the same time, we provide a place (Eg. the Credentials store) that can be used to hold public keys associated with individual subscribers.
Now I will admit that I haven't thought about the criteria associated with permitting someone to add a public key-->user association. But, within whatever policy is needed, we have a method to handle the storage and the framework within which the system can "GetUserByCredential()", etc.
Richard
On Apr 30, 2013, at 12:28 AM, Stephen J. Turnbull <stephen@xemacs.org> wrote:
Terri Oda writes:
- I would like to remind/tell you all that FOR THIS RELEASE, we will ONLY be supporting Mozilla Persona and passwords as authentication methods.
- While I agree that thinking about these things in advance is useful, I think this discussion is starting to crowd out discussions of time-sensitive things like students' GSoC applications and architectural choices that directly impact how they write said applications.
Hold on! Who's "we" and what is being released? There are at least 3 more or less separate projects here (Mailman core, Postorius, and HyperKitty). For login of the webapps Postorius and HyperKitty, I certainly agree that aiming releasing them simultaneously with core 3.0, focusing on a particular authn mechanism (and given work done at the sprints, it should be Persona) is appropriate.
But Mailman 3.0 is *not* the only item on the agenda here. We have a pile of GSoC students who want to implement various forms of authn for Mailman core functionality (secure lists) and some REST API (not clear to me which subproject these adhere to, the core Mailman REST API or a new one to be provided by Postorius). AFAICT, *Persona is not appropriate* for these use cases, as it implies interactive use of a full-featured web browser.
Are you saying that (despite our ideas page) these proposals are a priori nearly unacceptable? It's also rather late in the process to change the rules on the students: if experience is any guide, Melange availability is going to start deteriorating soon.
So... can we please backburner parts of this discussion until after GSoC so that we don't make it impossible for anyone to start on any project involving extra profile info? I don't want to bog down a student with the need to make this choice and work with these decisions at this stage.
Actually, there aren't any students explicitly discussing extra profile information in their proposals. They talk airily about "extended REST API" or similarly generic terms. None talk about storage or representation of profile information. (OK, it was 3am, my memory is fallible. I don't remember any, though.)
For the purposes of GSoC this summer:
Authentication for the purposes of the extra profile info data store will be provided by either Persona through the web interface or passwords.
OK.
Yes, even internally for the REST interface: passwords+localhost are good enough for Mailman Core right now, so it's good enough for anything else we do short-term.
That's going to strongly bias decision-making against at least one REST API proposal, which was made in good faith.
It also formally seems to rule out the secure lists proposal, which obviously depends on an off-line non-localhost authn protocol (based on OpenPGP or S/MIME). Is that your intention?
Regards,
Richard,
- Richard Wackerbarth <rkw@dataplex.net>:
Again, we agree. (Something must be wrong :) ) I think that it is important that "we" (the senior developers and mentors) assure that we maintain a structure whereby each of the student proposals can proceed at the same time.
I believe you have been asked very politely not to continue this thread yesterday and give way for more pressing topics such as GSoC. Can you please do so?
p@rick
-- [*] sys4 AG
http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein
Patrick,
This IS about GSoC. If we accept Terri's position, as stated and without question, then we are, de facto, eliminating some of the proposals based only on subject matter. The students making these proposals are doing so in good faith, and often based on "ideas" provided by our organization.
I consider that doing so is totally inappropriate. As I state, we need to maintain a structure whereby each of the proposed projects can proceed without being blocked by another project, but done in such a manner that they can be integrated into the whole as they develop into functioning code.
Richard
On Apr 30, 2013, at 5:47 AM, Patrick Ben Koetter <p@sys4.de> wrote:
Richard,
- Richard Wackerbarth <rkw@dataplex.net>:
Again, we agree. (Something must be wrong :) ) I think that it is important that "we" (the senior developers and mentors) assure that we maintain a structure whereby each of the student proposals can proceed at the same time.
I believe you have been asked very politely not to continue this thread yesterday and give way for more pressing topics such as GSoC. Can you please do so?
p@rick
-- [*] sys4 AG
http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein
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
On Apr 30, 2013, at 5:47 AM, Patrick Ben Koetter <p@sys4.de> wrote:
I believe you have been asked very politely not to continue this thread yesterday and give way for more pressing topics such as GSoC. Can you please do so?
This is in rather bad taste. Richard and I have been actively involved in mentoring the GSoC students, and we care about them. Please respect that, at least to the extent of reading the messages we write about the project.
Richard Wackerbarth writes:
I consider that [a priori ruling out submitted proposals] is totally inappropriate.
I won't go so far as to say "totally" inappropriate. We do have to get some work done, and if the consensus is that strict adherence to the letter of Terri's post is the best way to move along ... I'll deal with it. I hope we can find a compromise, though.
Steve
On 13-04-29 11:28 PM, Stephen J. Turnbull wrote:
Actually, there aren't any students explicitly discussing extra profile information in their proposals. They talk airily about "extended REST API" or similarly generic terms. None talk about storage or representation of profile information. (OK, it was 3am, my memory is fallible. I don't remember any, though.)
Oh! I think I understand some of the confusion now. I thought I'd said at the beginning why I was starting this thread at all, which is primarily because Systers has a student project that needs extra profile info. There are also a collection of students with minor features that would use the data store that they've used to pad out projects that might otherwise be too short (For example, see some of the ideas Peter Markou mentioned in his recent post). But now that you mention it, I've been talking to a lot of folk on IRC and they often don't tell me if they're applying with Mailman or Systers, so maybe there's more of them with Systers than with Mailman?
For those not familiar, Systers runs a heavily modified version of Mailman 2.1. They'd like to switch to Mailman 3 shortly after we release Mailman Suite (whenever that's going to be), but they've got a few features that they'll need to either have integrated to core Mailman or maintained as branches. This year, they've got a project set up to port one of them to Mailman 3/Postorius as part of preparing them for that.
The specific feature they're hoping to add this year stores essays that people write when they subscribe. It's currently done with a database grafted on to Mailman 2.1 that was being used for another extended feature, but obviously if we're going to mentor such a project for Mailman 3, we'd like to use something at least approximating a real data store design. The problem is that the Systers mentors are mostly used to systers-mailman, based on 2.1, and I'm not sure anyone will have the Mailman 3.0 knowledge to guide a student through a halfway reasonable design, so I asked here in order to help them out so that their student could start on the essays (likely to be the easier part of her project) right at the beginning of the GSoC period. If we can't come to a moderate consensus on that design, I should be telling the Systers folk that this project won't be able to run this year, but I honestly figured we'd have a simple design after a couple of posts... I wasn't counting on authentication blowing up to a huge argument, and I don't have time for it do so if we want to make a good decision about this specific project.
So yeah, totally cool to be thinking about the more advanced projects in general, but I started this thread due to a specific need for a "good enough approximation for this Mailman suite release" version of the extra data store, and I still need a consensus on that that's either implemented or simple enough for a student to do in the first week of GSoC. I think we're pretty close to that point, but I'm not sure it's yet described in a way that we can hand it off safely to a student and get a REST API that actually meaningfully matches the discussion within a couple of days. Probably we need an actual set of doctests for the student to work against next and then we'll be there.
Incidentally, I've been trying to get the students interested in this particular Systers project to come to this mailing list and join in the discussion, but it's become *very* intimidating to take part in this thread, which is the other reason I need folk to take a step back.
Terri
Terri,
For Systers, is it better to try to access Postorius through its REST API or by directly including it as a django app?
In particular, using Django 1.5 and the custom user module feature that it provides along with the scheme that I outlined earlier provides an easy path to developing and integrating features such as the essays into the user profile. Basically, we share a common User model. Someone can start by using the standard django.contrib model and ignore the Postorius specific parts.
I am willing to implement the pieces (I estimate needing only a day or two if I do a simple version), but I also think that it would be an appropriate task for one of the students.
Richard
On Apr 30, 2013, at 10:31 AM, Terri Oda <terri@zone12.com> wrote:
On 13-04-29 11:28 PM, Stephen J. Turnbull wrote:
Actually, there aren't any students explicitly discussing extra profile information in their proposals. They talk airily about "extended REST API" or similarly generic terms. None talk about storage or representation of profile information. (OK, it was 3am, my memory is fallible. I don't remember any, though.)
Oh! I think I understand some of the confusion now. I thought I'd said at the beginning why I was starting this thread at all, which is primarily because Systers has a student project that needs extra profile info. There are also a collection of students with minor features that would use the data store that they've used to pad out projects that might otherwise be too short (For example, see some of the ideas Peter Markou mentioned in his recent post). But now that you mention it, I've been talking to a lot of folk on IRC and they often don't tell me if they're applying with Mailman or Systers, so maybe there's more of them with Systers than with Mailman?
For those not familiar, Systers runs a heavily modified version of Mailman 2.1. They'd like to switch to Mailman 3 shortly after we release Mailman Suite (whenever that's going to be), but they've got a few features that they'll need to either have integrated to core Mailman or maintained as branches. This year, they've got a project set up to port one of them to Mailman 3/Postorius as part of preparing them for that.
The specific feature they're hoping to add this year stores essays that people write when they subscribe. It's currently done with a database grafted on to Mailman 2.1 that was being used for another extended feature, but obviously if we're going to mentor such a project for Mailman 3, we'd like to use something at least approximating a real data store design. The problem is that the Systers mentors are mostly used to systers-mailman, based on 2.1, and I'm not sure anyone will have the Mailman 3.0 knowledge to guide a student through a halfway reasonable design, so I asked here in order to help them out so that their student could start on the essays (likely to be the easier part of her project) right at the beginning of the GSoC period. If we can't come to a moderate consensus on that design, I should be telling the Systers folk that this project won't be able to run this year, but I honestly figured we'd have a simple design after a couple of posts... I wasn't counting on authentication blowing up to a huge argument, and I don't have time for it do so if we want to make a good decision about this specific project.
So yeah, totally cool to be thinking about the more advanced projects in general, but I started this thread due to a specific need for a "good enough approximation for this Mailman suite release" version of the extra data store, and I still need a consensus on that that's either implemented or simple enough for a student to do in the first week of GSoC. I think we're pretty close to that point, but I'm not sure it's yet described in a way that we can hand it off safely to a student and get a REST API that actually meaningfully matches the discussion within a couple of days. Probably we need an actual set of doctests for the student to work against next and then we'll be there.
Incidentally, I've been trying to get the students interested in this particular Systers project to come to this mailing list and join in the discussion, but it's become *very* intimidating to take part in this thread, which is the other reason I need folk to take a step back.
Terri
Terri Oda writes:
Oh! I think I understand some of the confusion now. I thought I'd said at the beginning why I was starting this thread at all, which is primarily because Systers has a student project that needs extra profile info.
That was a long time ago, and ... none of the students actually applying to Mailman has expressed direct interest in the extra profile info. To the contrary, a couple have commented that crypto really interests them.
stylistica posted here and has been on IRC off and on, but hasn't applied through Mailman. dardie will need a profile API, I think, but *her* proposal just showed up in the last hour or so and is an early draft.
The problem is
... somebody who knows the requirements needs to explain them on *Mailman* channels. We (more precisely, you, 'cause I don't know who to ask) need to get the principals in here, or in a conversation off-list. Then we'll work it out.
participants (4)
-
Patrick Ben Koetter -
Richard Wackerbarth -
Stephen J. Turnbull -
Terri Oda