Difference between revisions of "Infrastructure Team/Central Login"

Revision as of 13:44, 28 September 2011

This is initiative to permit a user to access multiple SL resources while providing their credentials (such as userid and password) only once.

Single sign-on for all Sugar Labs services, and, in theory, for any Sugar related sites that want to get the benefits from Sugar Central Login (there is no need to be hosted on Sugar Labs' servers per se, only authentication for the target site will happen in a centralized manner).
Centralized users database.
Reuse users database not only for Web services, but also for shell accounts, for example.

To be accounted.
- Be counted is a sign-less instrument, the sing depends on an intention (SL here is out of suspicions) and doers' professionalism (yep, thats the question). And for not being counted, there is only one option - not being counted anywhere, i.e., out of Login usecase at all. --alsroot 12:46, 28 September 2011 (EDT)
Different authentication methods provide different levels of protection from those who wish to abuse Sugar Labs resources. While making it easier to participate, we will likely suffer some abuse during the interim, until we, or the industry, learn to better filter those with ill intentions. --FGrose 13:26, 28 September 2011 (EDT)
- This point belongs to Benefits as well, e.g., if most of services will use CAS, we will have only one, well controlled, access point. --alsroot 13:40, 28 September 2011 (EDT)

A list of possible authenticate front-ends:

CAS, the most common method, with a requirement to provide login/password, is useful for people who are not arriving from a Sugar Shell instance (and so, Sugar's certificate-based method does not work implicitly for them), and for casual visitors or those wishing to avoid the technical work of taking care of user side certificates. The full featured option.
OpenID authentication. Would be useful if particular service can link OpenID users and the ones got from CAS/LDAP. Without that, OpenID is just a standalone authentication method for particular service that does not relate to Central Login at all.
Users certificates. Might be useful, e.g., for people who need to be authenticated from a Sugar Shell where Sugar might perform some authentication routines under the hood.
Any method that can process authentication via LDAP, to reuse centralized users database only (no single sign-on).

This application is needed to accomplish several tasks related to account management procedures for regular users, such as:

Let people create an account on the LDAP server using the regular, for Web services, Sign-on workflow, i.e., in an automatic manner. It would be useful to have instruments to prevent automated software from performing registration.
Have a "Forgot password" feature.
Edit LDAP metadata. It would be useful to let people authenticate on CAS, i.e., to avoid typing passwords twice, once to get access to a service and a second time in Account management applications before editing account metadata.

@@ Line 27: / Line 27: @@
 == Authenticate front-ends ==
+A list of possible authenticate front-ends:
 * [[wikipedia:Central_Authentication_Service |CAS]], the most common method, with a requirement to provide login/password, is useful for people who are not arriving from a Sugar Shell instance (and so, Sugar's certificate-based method does not work implicitly for them), and for casual visitors or those wishing to avoid the technical work of taking care of user side certificates. The full featured option.