Changes

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