Difference between revisions of "Infrastructure Team/Central Login"

From Sugar Labs
Jump to navigation Jump to search
Line 21: Line 21:
 
== Authenticate front-ends ==
 
== Authenticate front-ends ==
  
Preliminary list of possible front-end methods to authenticate users.
+
* [[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.
 
+
* [http://en.wikipedia.org/wiki/OpenID 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.
* [[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.
+
* 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. To be useful, this feature needs to use LDAP.
* Users certificates are useful 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''.
* [http://en.wikipedia.org/wiki/OpenID OpenID] authentication.
 
* Some services, e.g., https://obs.sugarlabs.org, requires Basic HTTP authentication by design.
 
  
 
== Authenticate back-end ==
 
== Authenticate back-end ==
  
 
* ldap.sugarlabs.org
 
* ldap.sugarlabs.org

Revision as of 11:43, 28 September 2011

Summary

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

Benefits

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

Resources to authenticate on

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. To be useful, this feature needs to use LDAP.
  • Any method that can process authentication via LDAP, to reuse centralized users database only.

Authenticate back-end

  • ldap.sugarlabs.org