In the cloud-based environment, we can distinguish the login behavior from locally login in a Chromium OS device and cloud login in the internet (Application in the Internet, such as facebook, twitter, web-based e-mail, etc.). Try to think a scenario that you have the different account name and different password for facebook, twitter, and webmail, separately. That means you should remember these different account names and passwords. Once you forget any password, and then you have to go through a long procedure to receive your password by the service provider. This makes user feel inconvenient. In addition, if user goes through many sites that require authentication, user must type his account name and password every time. We believe this will make user has a very bad experience in the scenario. For this reason, the Chromium OS device would provide a convenient way for user as easy as to log in to device and sites, but not reduce the security of user’s password.

1. Chromium OS Report Part 1
Login
In the cloud-based environment, we can distinguish the login behavior from
locally login in a Chromium OS device and cloud login in the internet (Application in
the Internet, such as facebook, twitter, web-based e-mail, etc.). Try to think a
scenario that you have the different account name and different password for
facebook, twitter, and webmail, separately. That means you should remember these
different account names and passwords. Once you forget any password, and then
you have to go through a long procedure to receive your password by the service
provider. This makes user feel inconvenient. In addition, if user goes through many
sites that require authentication, user must type his account name and password
every time. We believe this will make user has a very bad experience in the scenario.
For this reason, the Chromium OS device would provide a convenient way for user as
easy as to log in to device and sites, but not reduce the security of user’s password.
1. Design Philosophy
Figure 1 Design Philosophy
In this section, we illustrate the design philosophy of the Chromium OS device.
In general, an OS runs in the Internet environment, should care about the security

2. issues and the way for user can easy to use the cloud-based services.
1.1 Single Sign On (SSO)
This makes user can use to seamlessly access to cloud-based services.
1.2 Security and Easy-to-Use
This mechanism will be designed for security, privacy and easy-of-use.
1.3 Without Google Login
This can be separated by that supports OpenID for user to access Google services
or the services which are provided by other sites.
2. Objective
Because the Chromium OS device is a cloud-based device which is running in
the Network environment, user’s data should be bundled together and to know
which device to sync it down to. Initially, Google Chromium OS supports the user
needs to log in to the device with a Google account. The other authentication
methods are provided in the future, says Google’s Chromium OS Team.
The Google’s Chromium OS Team has defined the device will be able to
authenticate the user against Google. That means the service always uses the user’s
latest password, even if the user change his password in any time or in any place.
Assume that user has logged in online at least once, the user can enable to log in to
device when offline.
This device also supports a convenient way which is named SSO for user to
access the services in the cloud. The way allows user just signs his account once, and
then the other services do not require authentication. This helps user has a
seamlessly cloud environment.
Otherwise, user can also opt-in the auto-login with SSO, so that he does not need
additional authentication.
In the future, the Chromium OS device also supports alternative authentication
system, such as:
1. Give users an SSO experience at OpenID relying parties.
2. Give users an SSO experience at sites.
Google’s Chromium OS team is also investigating that allow users to log in to a
Chromium OS device using a non-Google OpenID provider and that how to enable 3rd
parties to provide interoperable sync service.
3. Design Highlights
They divide this topic into two phases. The phase 1 is discussing the currently
implementation of how to achieve authentication for login. They are using the
Google Accounts HTTP(s) API to authenticate users and get the appropriate cookies

3. to log the user in to all Google services by the libcurl which is provided by the Linux
PAM module (pam_google) in the device-side.
Once the user has successfully authenticated online, the PAM module caches a
mapping between the user and the SHA256 hash of his password. The mapping
cache is used to log in to device when the network is unavailable. In that case, no
cookies can be acquired. Therefore, we can have the unexpired cookies which is a
previous authentication already cached in the Chromium browser session. These
cookies can be used once for getting back online.
The login UI is the forked version of SLiM. This software provides theme that
users can apply many skins into login UI, so that users can change his personality of
user interface. In addition, users can also select the different keyboard layout and
locale on login screen or be selectable on the fly.
Unfortunately, the normal Google ClientLogin API is not enough for our need,
because the APIs are designed to provide cookies that allow a client application to
authenticate to a single Google service. If we want to get the cookies into Chromium
after the user’s session has begun, we have to do these steps:
1. Get a Google cookies (https://www.google.com/accounts/ClientLogin)
2. Get a one-time use token which is used to authenticate the user to any
service (https://www.google.com/accounts/IssueAuthToken)
3. Exchange the token for full set of browser cookies we need to do SSO
(https://www.google.com/accounts/TokenAuth)
In the future, Google’s Chromium OS team will provide other APIs for user to
reduce these steps.
Figure 2 The ClientLogin Authorization Process
Figure 1 show an installed application that wants to get the Google services.
This application can pass the authentication procedure by this workflow.
Otherwise, if an installed application wants to get OAuth, it can run through the
following workflow:

4. Figure 3 The OAuth Authorization Process for Installed Apps
When we surf in the Internet environment, there may have many attackers. For
security, we have to design a mechanism to prevent the attackers to trick user.
Because only root certificate that the login process is willing to trust to identify web
servers is the issues Google’s SSL cert, the attackers have to trick Google’s registrar
before they trick the registrar who sends the SSL cert for www.google.com.
For the auto-login, it’s not safe for that we cache the user’s password and
running it in normal login process. As auto-login is opt-in, this means that user has to
log in to Chromium OS device first, and then he can do this action. So this is a
web-based flow that results in the user getting an OAuth token that we cache.
Here we can divide this issue into two conditions:
1. Online: We store the token in the same encrypted-while-shutdown storage
as we’re using for system settings. If the token exchanging is successful, log
the user in. You can reference the Figure 4.
Shutdown & Encrypt token
Login Process would check it
(exchanging it for Google cookies)
Log the user in
Figure 4 Online Auto-Login
2. Offline: If the login process would need to proceed offline, then the
presence of the token is deemed to be enough to allow login to succeed.

5. The Figure 5 explains this scenario.
Shutdown & Encrypt token
Login Process would check it
(use the presence of the token)
Log the user in
Figure 5 Offline Auto-Login
The phase 2 is discussing the information sharing between browser and login
manager. When we would like to share code between them, particularly the network
configuration, we can use a tightly restricted version of the browser itself as the login
manager. If we don’t want to use the limited version of browser as the login manager,
we can instead of the “pipe” to receive Google cookies. It will use some other
system-wide IPC technique.
As for logging in to third-party sites for which the user has entered their
password already, such behavior will likely tied to a password sync system.