Infrastructure Team/Central Login: Difference between revisions
No edit summary |
discussion link |
||
| (3 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
== Summary == | == Summary == | ||
This is initiative to permit a user to access multiple SL resources while providing their credentials (such as userid and password) only once. | This is an initiative to permit a user to access multiple SL resources while providing their credentials (such as userid and password) only once. | ||
== Benefits == | == Benefits == | ||
| Line 8: | Line 8: | ||
* Centralized users database. | * Centralized users database. | ||
* Reuse users database not only for Web services, but also for shell accounts, for example. | * Reuse users database not only for Web services, but also for shell accounts, for example. | ||
* (a side-benefit) Education about the risks of inter-networked services. Most people have little understanding of such risks, their significance, or appropriate protective behaviors. | |||
== Costs == | == Costs & Risks== | ||
* To be accounted. | * To be accounted. | ||
| Line 16: | Line 17: | ||
*: This point belongs to [[#Benefits|Benefits]] as well, e.g., if most of our services will use CAS, we will have only one, well controlled, access point. --[[User:Alsroot|alsroot]] 13:40, 28 September 2011 (EDT) | *: This point belongs to [[#Benefits|Benefits]] as well, e.g., if most of our services will use CAS, we will have only one, well controlled, access point. --[[User:Alsroot|alsroot]] 13:40, 28 September 2011 (EDT) | ||
*:: There is an escalating intrusion/protection arms race on the Internet that challenges the most advanced providers of ethical services. Yes, we should seek to benefit from those efforts. --[[User:FGrose|FGrose]] 13:34, 5 October 2011 (EDT) | *:: There is an escalating intrusion/protection arms race on the Internet that challenges the most advanced providers of ethical services. Yes, we should seek to benefit from those efforts. --[[User:FGrose|FGrose]] 13:34, 5 October 2011 (EDT) | ||
* What risks are there after signing on from a public workstation and leaving one's authentication cookie behind, or otherwise loosing one's cookie? What responsible efforts should we undertake to get the vulnerable community to participate more safely? | |||
== Resources to authenticate on == | == Resources to authenticate on == | ||
| Line 51: | Line 53: | ||
* Have a "Forgot password" feature. | * 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. | * 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. | ||
== Motion == | |||
Basing on Infrastructure Team discussion, there is a motion: | |||
* Central [[wikipedia:Lightweight_Directory_Access_Protocol |LDAP]], i.e., centralized database of all users; | |||
* Support [[wikipedia:Central_Authentication_Service|CAS]] on as many as possible Sugar Labs sites; | |||
* Having users friendly (not only for geeks) [[#Account management application|Account management application]]; | |||
* If particular site supports OpenID as a second auth method, use it as a second auth scheme with CAS; | |||
* Push this new infra to production usage; | |||
* Look for more auth methods, like certs based auth from Sugar Shell, that might be useful in addition to the existing system. | |||
=== Discussion === | |||
[http://www.mail-archive.com/sugar-devel@lists.sugarlabs.org/msg23290.html sugar-devel thread] | |||