[Sugar-devel] Single sign-on for Sugar Labs resources

Aleksey Lim alsroot at activitycentral.org
Wed Oct 19 06:40:18 EDT 2011


On Wed, Oct 19, 2011 at 01:17:12PM +1100, James Cameron wrote:
> On Wed, Oct 19, 2011 at 01:10:22AM +0000, Aleksey Lim wrote:
> > This is an invitation to broad discussion and pointing out possible
> > down sides of this decision (in addition to [1]).
> 
> Costs and risks not mentioned in [1] might include:
> 
> * annoying everybody with extra effort, thus creating a temporary
> barrier to contributions,
> 
> * a single point of failure, when it fails, none of the resources can be
> used,
> 
> * complexity of solution may lead to longer time before service is
> restored,
> 
> * reduced number of engineers with sufficient understanding to be able
> to fix the service when it breaks,
> 
> ... and that these risks were not identified previously suggests to me
> that not enough consensus has been reached, and that the decision to
> proceed is hasty.

My own conclusion during the discussion within systems@ mailing lists is
that we mostly have the same weight negative sides for SSO and
not-doing-anything cases, e.g., for risks you mentioned I might provide:

* it is exactly about having lower barriers; yes, for some people it
  will mean one time effort (to read notification email, and use only
  one account for all SL resources), but after that, the barriers will
  be lower by reusing SSO;

* yes, adding new code (because not all SL resources support CAS) means
  adding new point of breakage, but it is natural risk for any kinds of
  doing, the only not-doing means not having problems; in my mind it is
  the case when benefits outweighs risks;

* the same as ^;

* yes, it is exactly about reducing of engineers who need to take care
  about users authentication and users db, because we will have single
  point for that for all SL resources, i.e., minimizing maintainance
  costs;

i.e., it was actually somehow discussed within the systems at . So, my copy
pasted systems@ conclusion:

In my mind, we have similar contras for both ways (the current one
and the new one with central users db and single sign-on). But in my mind,
if there is no obvious winner/looser, better to be lead by pros rather
by contras, i.e., I see how central db and single sign-on will be useful
for positively oriented people to easy behave on SL sites. And yes, we
will have to deal with situations like cracking the central db and spam on
all SL resources, but it is for me an inevitable [big] minuses for big
pluses.

-- 
Aleksey


More information about the Sugar-devel mailing list