Search
Clear search
Close search
Google apps
Main menu

Configure SAML Single Sign-On for Chrome devices

Security Assertion Markup Language (SAML) Single Sign-On (SSO) support for Chrome devices allows users to sign in to a Chrome device with the same authentication mechanisms that you use within the rest of your organization. Their passwords can remain within your organization's Identity Provider (IdP). Signing in is very similar to signing in to a Google Apps account from a browser via SAML SSO with Google Apps. However, because a user is signing in to a device, there are several additional considerations.

Requirements

  • Chrome device running Chrome OS version 36 or higher
  • Domain configured for SAML SSO for Google Apps
  • SAML URL using HTTPS not HTTP
  • Chrome management licenses

Step 1:

If you haven’t already, set up SSO with your Google Apps account.

Step 2:

Set up and test SAML SSO on a test domain you own. If you don’t have a test domain, test SAML SSO with a small number of users by creating a test group and enabling SSO for users only in that group. After testing SAML SSO with a small number of users, roll it out to approximately 5% of your users.

  1. In the Google Admin console, click Device Management > Chrome management > User Settings.
  2. Under Single Sign-On, choose Enable SAML-based Single Sign-On for Chrome Devices from the drop-down menu.
  3. Click Save Changes.

Step 3 (Optional):

To allow Single Sign-On users to log in to internal websites and cloud services that rely on the same Identity Provider on subsequent sign-ins to their Chrome device, you can enable SAML SSO cookies.

Go to Device management > Chrome management > Device Settings > Single Sign-On Cookie Behavior. Learn more about this setting.

Step 4 (Optional):

To allow Single Sign-On users to navigate directly to your SAML IdP page instead of first having to type in their email address, you can enable SAML SSO IdP Redirection.

Go to Device management > Chrome management > Device Settings > Single Sign-On IdP Redirection. Learn more about this setting.

Step 5:

After testing SAML SSO for Chrome devices on 5% of your organization, you can roll it out to everyone by enabling the same policy for additional groups. If you run into issues, contact Google for Work Support.

After configuration, users will see the following steps when they sign in to a Chrome device.

Sign in to a Chrome device with SAML Single Sign-On

Once SAML SSO on Chrome devices has been configured for your organization, users will see the following steps when they sign in to a Chrome device.

Requirements

Sign-in Sequence:

Instruct your users to do the following when first signing in to their Chrome device. Note: You will need to test this before rolling it out to your organization.

  1. Enter your username (full email address) on the Chrome device sign in page. A password is not needed in this step.

  2. You will be taken to your organization’s SAML SSO page. Enter your SAML credentials on the SAML provider login page.

  3. If prompted, re-enter your password to complete sign-in. This step is only necessary if your Identity Provider has not yet implemented the Credentials Passing API. This is necessary to allow offline access to your Chrome device and also to be able to unlock it.

  4. When signed in successfully, your session starts and the browser opens. The next time you sign in, you will only need to enter your password once when you start up your Chrome device. If you run into issues, please contact your IT administrator.

FAQs

After signing in with my SAML provider, I am prompted to re-enter my password. Is that normal?

Yes. This is necessary to allow offline access to your Chrome device and to be able to unlock it. We have an API that SAML vendors can implement to remove the need for this confirmation step.

If a user changes their password on another device, how do you make sure the Chrome device gets updated to unlock with the new password?

We recommend you use the simple update method on our Directory API which will notify our authentication server when a password is changed. Enter the password value in the Request body. If the API is not used, the password change will be detected at the next online login flow. By default, the Chrome device will force an online sign in every 14 days even if the password didn't change. You can change this period in the Admin console by going to Device Management > Chrome Management > User Settings > Single Sign-On Online Login Frequency.

My password has special characters, will it work?

We support ASCII printable characters only.

I see the screen “Oops, couldn't sign you in. Sign-in failed because it was configured to use a non-secure URL. Please contact your administrator or try again”. What should I do?

If your employees are reporting this error message, it means that the SAML IdP is trying to use an HTTP URL and only HTTPS is supported. It is important that the entire sign-in flow uses HTTPS only. So even if the initial sign-in form is served over HTTPS, you can get this error if your IdP redirects to an HTTP URL somewhere later in the process. If you fix this and users are still getting the error message, please contact Google for Work Support.

I am an IT administrator. Why am I am not being redirected to my SAML Identity Provider?

This is by design. In the event of something going wrong during setup, we still want the administrator to be able to login and troubleshoot the problem.

Does SSO work with SSL content filters?

Yes. Please follow Set up SSL inspection on Chrome devices for setup. In addition to whitelisted domains documented in Set up a host name whitelist, you also need to whitelist your SSO Identity Provider domain and www.google.com.

How does SSO work with camera permissions?

To give third party software direct access to the device camera on behalf of your SSO users, you can enable Single Sign-On camera permissions.

Go to Device management > Chrome management > Device Settings > Whitelist of single sign-on camera permissions. Learn more about this setting.

By enabling this policy, the administrator grants third parties access to their users' cameras on their users' behalf. The administrator should ensure that they have proper consent forms in place for users as the system does not show end users any consent forms once camera permission is granted via this policy.

 

 

Was this article helpful?