[Systers-dev] Project Using Mailman Authentication

[A-M Horcher]

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