[Systems] SL Central Login

[Aleksey Lim]

On Wed, Sep 28, 2011 at 05:07:31PM +0000, Aleksey Lim wrote:
> On Tue, Sep 20, 2011 at 12:42:47PM +0000, Aleksey Lim wrote:
> >
> > I think it will be useful to start settling down the question about
> > common SL login system, At least the system, Sweets[1], whose testing version
> > I'm hopping to publicly anounce this week, after trying to do that at
> > Sep 18, will require being authed to release new sofware versions within
> > this new system. For now it uses CAS on top of our LDAP but there are
> > several issues:
> > 
> > * to have LDAP record, people need to request for shell account (but
> >   there is no need in shell account for Sweets at all, only being
> >   authenticated)
> > * the process to create this account is not users friendly at all
> >   (email request to RT)
> > 
> > I guess we need to collect all info related to central login on, e.g., [2]
> > and have an infrastructure meeting to discuss how [2] might be
> > implemented.
> > 
> > [1] http://wiki.sugarlabs.org/go/Platform_Team/Sweets
> > [2] http://wiki.sugarlabs.org/go/Infrastructure_Team/Central_Login
> 
> The picture I have in mind is on [2], There is an application to implement [3]
> (we, with Bernie) did not manage to find ready-to-use solution.
> 
> Would be useful to polish [2] to have a consensus within systems at . Then,
> push it widely to discuss and ask for [3] implementers.
> 
> [3] http://wiki.sugarlabs.org/go/Infrastructure_Team/Central_Login#Account_management_application

ping...

In my mind, we have similar contras [4] 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.

What about having:

* central ldap,
* support cas on as many as possible SL sites,
* having users friendly (not only for geeks) [3],
* if particular site supports OpenID as a second auth method,
  use it as a second auth scheme w/ cas,
* push previous points to the production
* look for more auth methods like certs based auth from Sugar Shell. 

Do we have a consensus on non-tech stuff within the systems@ to publicly
announce ^ (and maybe revisit some points) and look for ideas/doers for [3]?

-- 
Aleksey