[Systers-dev] Project Using Mailman Authentication

[A-M Horcher]

I actually have that included a role modelling as an alternate project in my
proposal.  The idea of single sign-on to various systers offerings is very
convenient to the users, and also sets us up to leverage improvements in one
subsystem to another.

The ability to search archives goes hand-in-hand with the ability to peruse
the essays described in the admin interface overhaul.  Similar look and feel
between the registration interface and the search interface will benefit the
user.

Centralizing the user information to relate to the various subsystems also
gives a foundation for expanding Systers offerings, such a Systers speaker
bureau.  (like Fatima tied into for her program in Sudan)


On Mon, Apr 5, 2010 at 11:23 PM, Robin Jeffries <robin at jeffries.org> wrote:

> Interesting topic.  Hadn't really thought deeply about the need for roles
> here.
>
> Mailman has several levels of administrative roles (list moderator --
> approves new subscriptions and posts, list owner -- does everything, and
> site owner -- does everything for all lists.  There might be another role
> called list creator, but I think we just give that to the site owner).
> Mailman does it by having distinct passwords for each role, rather than
> assigning people to the role, so that will take work to graft onto mailman
> (but I don't know how mailman 3.0 does it)  I can imagine administrative
> roles for other apps, so someone having list owner for a mailing list might
> not also have administrator for the wiki.  We definitely need the
> sophistication of giving a single person multiple roles (though that always
> has the challenge of them having more power than they need at a given moment
> and screwing up because of it).
>
> Beyond the admin roles, systers (this might not be true of other orgs that
> want to use this) is pretty egalitarian.  We are all technologists, so it
> makes sense for everyone to be able to edit the wiki (though I suppose that
> some parts could belong to particular lists) and similar stuff.  So I don't
> think there were need to be a plethora of roles, but having enough
> flexibility to enable different types of administrator is an important thing
> to think about (Malveeka can talk about how well that was integrated into
> last year's approach).
>
> Robin
>
>   On Sun, Apr 4, 2010 at 8:59 PM, A-M Horcher <horcheram at gmail.com> wrote:
>
>>  The use of OpenID as an authentication method will potentially improve
>> the
>> quality of the authentication.  Currently, the mailman interface warns the
>> user that the password will be communicated in clear text.
>>
>> The use of a database to store and interact with the information is a
>> great
>> first step.   The next step typically taken is to introduce the concept of
>> roles for the users interacting with the Systers system.  Roles are
>> usually
>> described by characteristics the users have, and activities/interactions
>> with the system they are allowed to perform  Extending your concept
>> further,
>> here are some possible roles to illustrate the concept:
>>
>> Development List User
>> IS:      anyone, not required to be a member of Systers, interest in dev
>> CAN:- can contribute to the development list, can work on development code
>>
>> Systers GSOC Developer
>> Is:      GSOC accepted student, already a dev list user
>> Can:  make changes to a isolated dev environment, submit changes for the
>> Systers development server for specific sections of code, view other
>> developers queued changes, test other developers changes
>>
>> Systers GSOC Mentor
>> Is:      GSOC official mentor for a specific GSOC project, Systers member,
>> dev list member
>> Can:  view development environment, test changes, view queued changes
>>
>> Systers GSOC Administrator
>> Is:       Systers member, Dev list member, Systers staff (probably)
>> Can:    commit changes to development environment, approve changes, review
>> documentation
>>
>> Sometimes  the roles will fall into a natural hierarachy (straight line)
>> or
>> may fall into groupings.   The straight line is the easiest to design, but
>> the least flexible in giving specific authority to specific users.   In
>> deciding who can do what, the risk of granting too much access needs to be
>> balanced with the inconvience of administration.  If you have multiple
>> people making changes to a system, there should some controls to make
>> changes are approved, and that they can be reversed.
>>
>> The consistent information about the user, such as the authentication
>> method
>> like OpenID, is normally stored in one table. Depending on performance, or
>> the number of roles a user might or does have, it may be helpful to
>> abstract
>> the roles definitions to a separate table, and connect a user with the
>> role(s) they are assigned.
>>
>> This foundation for an interaction or security model makes the addition of
>> capabilities such as the wiki, etc. less cumbersome to the user.
>>
>> On Sat, Apr 3, 2010 at 12:37 PM, Jaideep Khandelwal <jdk2588 at gmail.com
>> >wrote:
>>
>> > After going through what Robin discussed and making a draft of what I
>> think
>> > to carry forward the mailman authentication for single sign on for the
>> > Systers i have come with the plan :
>> >
>> > 1. As the last year Malveeka's project was to use a separate database
>> table
>> > for OPEN ID'S to internal mailman  users and providing a seprate UI for
>> the
>> > users registering at systers mailing list , so I would like to continue
>> > with
>> > Malveeks'a code
>> >
>> > 2. If a new user comes to any of the systers site like wiki,mailing list
>> ,
>> > she registers so we  add an attribute in the form  of a openid url , the
>> > data gets store into the databse and for further use it will contact
>> > systers
>> > open id provider which will be redundant and restricted to be used with
>> > systers sites only.
>> >
>> > Suggestions are welcomed
>> >
>> >
>> > To unsubscribe from this conversation, send email to <
>> > systers-dev+mentor+unsubscribe at systers.org<systers-dev%2Bmentor%2Bunsubscribe at systers.org>
>> <systers-dev%2Bmentor%2Bunsubscribe at systers.org<systers-dev%252Bmentor%252Bunsubscribe at systers.org>>>
>>
>>
>> > or visit <
>> > http://systers.org/mailman/options/systers-dev?override=67&preference=0
>> >
>> > To contribute to this conversation, use your mailer's reply-all or
>> > reply-group command or send your message to
>> systers-dev+mentor at systers.org <systers-dev%2Bmentor at systers.org><
>> systers-dev%2Bmentor at systers.org <systers-dev%252Bmentor at systers.org>>
>> > To start a new conversation, send email to <systers-dev+new at systers.org<systers-dev%2Bnew at systers.org>
>> <systers-dev%2Bnew at systers.org <systers-dev%252Bnew at systers.org>>
>>
>>  > >
>> > To unsubscribe entirely from systers-dev, send email to <
>> > systers-dev-request at systers.org> with subject unsubscribe.
>> >
>>
>>
>> To unsubscribe from this conversation, send email to <
>> systers-dev+mentor+unsubscribe at systers.org<systers-dev%2Bmentor%2Bunsubscribe at systers.org>>
>> or visit <
>> http://systers.org/mailman/options/systers-dev?override=67&preference=0>
>> To contribute to this conversation, use your mailer's reply-all or
>> reply-group command or send your message to
>> systers-dev+mentor at systers.org <systers-dev%2Bmentor at systers.org>
>> To start a new conversation, send email to <systers-dev+new at systers.org<systers-dev%2Bnew at systers.org>
>> >
>> To unsubscribe entirely from systers-dev, send email to <
>> systers-dev-request at systers.org> with subject unsubscribe.
>>
>
>