My favorites | Sign in
Project Home Downloads Wiki Issues Code Search
New issue   Search
for
  Advanced search   Search tips   Subscriptions
Issue 182167: Support non-google accounts on login
33 people starred this issue and may be notified of changes. Back to list
 
Project Member Reported by wad@chromium.org, Nov 5, 2009
We need to determine the best path forward for supporting non-google 
accounts based login in a lightweight, user-friendly way.

There are many authentication options out there -- ranging from proxying 
account details to a chosen backend to figuring out how to use openid for 
client login cleanly.  Any changes here will also affect offline login, screen 
locking, and data encryption as well as some online interactions, so it's not a 
trivial change.

This may spawn other subtasks or after #315, may be a reasonable amount of 
work to track here.
Mar 11, 2013
#1 lafo...@gmail.com
(No comment was entered for this change.)
Blockedon: chromium-os:315
Nov 20, 2009
#2 m0.inter...@gmail.com
If you make it into openid, you will make many users/vendors happy!
Nov 20, 2009
#3 derat@chromium.org
 Issue 649  has been merged into this issue.
Jun 28, 2010
#4 cmasone@chromium.org
(No comment was entered for this change.)
Labels: -Area-Login Area-Auth
Aug 3, 2010
#5 or...@chromium.org
(No comment was entered for this change.)
Labels: Team-Systems
Aug 4, 2010
#6 or...@chromium.org
Bulk edit to use Est- instead of Effort- for open issues that are not marked V1.0FR
Labels: -Effort-3 Est-21
Aug 19, 2010
Project Member #7 su...@chromium.org
(No comment was entered for this change.)
Labels: -Mstone-R8 Mstone-X
Oct 7, 2010
#8 faldeg...@gmail.com
I would like something user friendly and domain based. Like username:user@domain.tld passwd:********, that logs in on something managed by that domain.

As far as I know there is no existing standard that can handle that from a domain login perspective. 

OpenID does not embed information like this but also require the user to specify authentication provider. That is not user-friendly. Teaching users how to do the above is hard enough.

The domain information should be enough to find a server that assist in the authentication process.

As users are used to entering domain in their email it will be easy to teach them to log in "with their email"...

I have been thinking a lot on this and a simple yet advanced mechanism need to be constructed. Think of how LAN networking use to have domain login, login scripts and push settings from a server.

On some domains you may want to run a simple longinscript and mount a few shares. On some you may want to initiate chromoting, and on yet others you may simply want chrome to log in to a web site. If you are in hurry you may just want to log in to username@gmail.com and access your mail, without having access to the rest of the Internet.

Jan 20, 2011
#9 kanhaiya...@gmail.com
At present how can I login into the system without the open ID concept?


Thanks and regards,
Kanhaiya 
Jan 20, 2011
#10 cmasone@chromium.org
Does using your gmail account not work?
Jan 20, 2011
#11 faldeg...@gmail.com
Technically LDAP would be one possibility, but it requires a way to configure what LDAP server to use. Thereby my suggestion on having a protocol that tells the login manager what to do.
Jan 20, 2011
#12 cmasone@chromium.org
Yes, we've been thinking a lot about this as well, and for a long time now.  We are moving to a web-based login flow, which will provide a platform upon which we can build to enable a multitude of federated login schemes.
Jan 20, 2011
#13 faldeg...@gmail.com
With web do you mean HTML or Web Service? Both are web, but there is a big difference. :)
Jan 20, 2011
#14 kanhaiya...@gmail.com
it worked using gmail, but I wanted to test it for other mail ids like rediffmail, yahoomail,etc. 
    
  
      
     

 
 


Jan 20, 2011
#15 cmasone@chromium.org
I assume you're using "Web Service" to mean a programmatic API that happens to be run over HTTP?  That's what we're using now, the Google Accounts programmatic login API.  It's deprecated, though, so we are moving to a scheme that allows an arbitrary web flow to communicate authentication status back to the platform.  I geuss, in your nomenclature, that'd be "HTML", though the term doesn't really apply.  The whole settings UI is written in HTML and JS, but it's not actually web-based in any meaningful way.
Jan 20, 2011
#16 faldeg...@gmail.com
Yeah, i am referring to the client/server protocol and what on a high lever would be an API.

More specifically i am thinking about the role of PAM in Linux and GINA in Windows. I am also thinking about the GINA login box "domain", "user", "pass" that in this case would be the "html/js" part.

In fact i asked because i think that in enterprise environment administrators may want the OS to start taking directions as early as possible. There are some configuration that need to be a local state like a static IP and i think specifying a login server could be done here. The server could then do stuff with the client even before the login window is shown. Perhaps even show its on login window.
Jan 20, 2011
#17 cmasone@chromium.org
We already have a number of plans around enterprise support and login.  Stay tuned to the dev channel if you'd like to see these features early.
Oct 30, 2012
#18 benhe...@google.com
(No comment was entered for this change.)
Labels: -Mstone-X
Blockedon: -chromium-os:315 chromium-os:315
Oct 31, 2012
#19 benhenry@chromium.org
(No comment was entered for this change.)
Labels: -DesignDocNeeded
Mar 6, 2013
#20 lafo...@google.com
(No comment was entered for this change.)
Labels: OS-Chrome
Mar 9, 2013
#21 bugdro...@chromium.org
(No comment was entered for this change.)
Labels: -Area-Auth -Team-Systems Cr-UI-SignIn Cr-OS-Systems
Mar 20, 2013
#22 lafo...@google.com
(No comment was entered for this change.)
Labels: -Cr-UI-SignIn Cr-Services-SignIn
Nov 12, 2013
#23 l...@colleton.net
This is phase 2 of the design for Chromium OS login:
http://www.chromium.org/chromium-os/chromiumos-design-docs/login#TOC-Phase-2
Sign in to add a comment

Powered by Google Project Hosting