Your SlideShare is downloading. ×
Chromium OS - Login
Chromium OS - Login
Chromium OS - Login
Chromium OS - Login
Chromium OS - Login
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Chromium OS - Login

1,050

Published on

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, …

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.

Published in: Technology, News & Politics
2 Comments
0 Likes
Statistics
Notes
  • Be the first to like this

No Downloads
Views
Total Views
1,050
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
14
Comments
2
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Chromium OS Report Part 1 Login In the cloud-based environment, we can distinguish the login behavior fromlocally login in a Chromium OS device and cloud login in the internet (Application inthe Internet, such as facebook, twitter, web-based e-mail, etc.). Try to think ascenario that you have the different account name and different password forfacebook, twitter, and webmail, separately. That means you should remember thesedifferent account names and passwords. Once you forget any password, and thenyou have to go through a long procedure to receive your password by the serviceprovider. This makes user feel inconvenient. In addition, if user goes through manysites that require authentication, user must type his account name and passwordevery 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 aseasy 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 inthe Network environment, user’s data should be bundled together and to knowwhich device to sync it down to. Initially, Google Chromium OS supports the userneeds to log in to the device with a Google account. The other authenticationmethods are provided in the future, says Google’s Chromium OS Team. The Google’s Chromium OS Team has defined the device will be able toauthenticate the user against Google. That means the service always uses the user’slatest 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 todevice when offline. This device also supports a convenient way which is named SSO for user toaccess the services in the cloud. The way allows user just signs his account once, andthen the other services do not require authentication. This helps user has aseamlessly cloud environment.Otherwise, user can also opt-in the auto-login with SSO, so that he does not needadditional authentication. In the future, the Chromium OS device also supports alternative authenticationsystem, 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 aChromium OS device using a non-Google OpenID provider and that how to enable 3rdparties to provide interoperable sync service.3. Design Highlights They divide this topic into two phases. The phase 1 is discussing the currentlyimplementation of how to achieve authentication for login. They are using theGoogle 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 LinuxPAM module (pam_google) in the device-side. Once the user has successfully authenticated online, the PAM module caches amapping between the user and the SHA256 hash of his password. The mappingcache is used to log in to device when the network is unavailable. In that case, nocookies can be acquired. Therefore, we can have the unexpired cookies which is aprevious authentication already cached in the Chromium browser session. Thesecookies can be used once for getting back online. The login UI is the forked version of SLiM. This software provides theme thatusers can apply many skins into login UI, so that users can change his personality ofuser interface. In addition, users can also select the different keyboard layout andlocale 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 toauthenticate to a single Google service. If we want to get the cookies into Chromiumafter 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 toreduce 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 thefollowing workflow:
  • 4. Figure 3 The OAuth Authorization Process for Installed Apps When we surf in the Internet environment, there may have many attackers. Forsecurity, 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 webservers is the issues Google’s SSL cert, the attackers have to trick Google’s registrarbefore 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 andrunning it in normal login process. As auto-login is opt-in, this means that user has tolog in to Chromium OS device first, and then he can do this action. So this is aweb-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 loginmanager. When we would like to share code between them, particularly the networkconfiguration, we can use a tightly restricted version of the browser itself as the loginmanager. 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 othersystem-wide IPC technique. As for logging in to third-party sites for which the user has entered theirpassword already, such behavior will likely tied to a password sync system.

×