Configure SAML single sign-on for ChromeOS devices

Security Assertion Markup Language (SAML) single sign-on (SSO) support for ChromeOS devices allows users to sign in to a 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 Workspace account from a browser via SAML SSO. However, because a user is signing in to a device, there are several additional considerations.

Requirements

• ChromeOS device running version 36 or higher
• Domain configured for SAML SSO for Google Workspace
• SAML URL using HTTPS not HTTP
• ChromeOS licenses for your devices

To learn about validated enterprise identity providers that meet all ChromeOS requirements, see our Chrome Enterprise Recommended program.

Step 1: Set up SSO

If you haven’t already, set up single sign-on for managed Google Accounts using third-party Identity providers.

Step 2: Test SSO

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. Sign in to your Google Admin console.

   Sign in using your administrator account (does not end in @gmail.com).

2. In the Admin console, go to Menu  DevicesChromeSettings. The User & browser settings page opens by default.

   If you signed up for Chrome Enterprise Core, go to Menu  Chrome browserSettings.

3. To apply the setting to all users and enrolled browsers, leave the top organizational unit selected. Otherwise, select a child organizational unit.
4. Go to Security.
5. Click Single sign-on.
6. Select Enable SAML-based single sign-on for Chrome devices.
7. Click Save. Or, you might click Override for an organizational unit.

   To later restore the inherited value, click Inherit. 

(Optional) Step 3: Enable SAML SSO cookies

To allow single sign-on users to log in to internal websites and cloud services that rely on the same IdP on subsequent sign-ins to their device, you can enable SAML SSO cookies.

1. Sign in to your Google Admin console.

   Sign in using your administrator account (does not end in @gmail.com).

2. In the Admin console, go to Menu  DevicesChromeSettingsDevice settings.
3. To apply the setting to all devices, leave the top organizational unit selected. Otherwise, select a child organizational unit.
4. Go to Sign-in settings.
5. Click Single sign-on cookie behavior.
6. Select Enable transfer of SAML SSO cookies into user session during sign-in. For more details, see Set ChromeOS device policies.
7. Click Save. Or, you might click Override for an organizational unit.

   To later restore the inherited value, click Inherit. 

(Optional) Step 4: Keep local ChromeOS and SAML SSO passwords in sync

You can choose to sync ChromeOS device local passwords with users' SAML SSO passwords.

By default, the local password is updated every time users sign in online. You can configure how often users are required to sign in online using the SAML single sign-on login frequency or SAML single sign-on unlock frequency settings. However, some users might change their SAML SSO password before they’re required to sign in online again. If that happens, users continue to use their old local ChromeOS password until the next time they sign in online.

To keep the local ChromeOS password in sync with their SAML SSO password, you can force them to sign in online as soon as their SAML SSO password changes. That way, they update their ChromeOS password almost immediately.

1. To notify Google of user password changes, you can use any of the following;
   1. IdP integration—For example, if you use Okta, you can use Okta workflows. For details, see GitHub documentation.

   2. Microsoft Entra ID integration—Change Password Notifier (CPN for Microsoft Entra ID) notifies Google of Microsoft Entra ID password changes. For details, see Sync ChromeOS passwords using Change Password Notifier for Microsoft Entra ID.

   3. AD integration—Change Password Notifier for Active Directory (CPN for AD) notifies Google of Microsoft AD password changes. For details, see Sync ChromeOS passwords using Change Password Notifier for Active Directory.
   4. API integration—Integrate your IdP with the device token API. You can get the Chromedevice token API here. For details, see Enable API suite for cloud project.
2. Configure the relevant settings;
   1. SAML single sign-on password synchronization flows—Choose whether you want to enforce online sign-ins for the login screen only, or for both the login and lock screen. For details, see Set Chrome policies for users or browsers.
   2. SAML single sign-on password synchronization—Select Trigger authentication flows to synchronize passwords with SSO providers. For details, see Set Chrome policies for users or browsers.

(Optional) Step 5: Notify your users of upcoming password changes

You can ensure that users are informed of upcoming password changes on their ChromeOS devices.

Currently, password expiration notifications are not supported for Microsoft Entra ID.

Note: We recommend that you do either Step 4: Keep local ChromeOS and SAML SSO passwords in sync or Step 5 Notify your users of upcoming password changes, not both.

To inform users about upcoming password changes;

1. Using the Google Admin Console, set up single sign-on for managed Google Accounts using third-party Identity providers.
2. Configure SAML assertion for password expiry for your SAML SSO provider. See the example below.
3. Using the Admin console, configure the settings.
   1. SAML single sign-on login frequency—Enter a value that is smaller than the password expiration time. ChromeOS only updates its assertions during online logins. For details, see Set Chrome policies for users or browsers.
   2. SAML single sign-on password synchronization—Select Trigger authentication flows to synchronize passwords with SSO providers. Specify how many days in advance users should be notified. You can enter a value between 0 and 90 days. Left blank, the default value of 0 is used and users are not notified in advance, only when their password expires. For details, see Set Chrome policies for users or browsers.

Example AttributeStatement

In the example;

• Attribute name contains passwordexpirationtimestamp—The timestamp when the authenticating user's password will expire. Can be empty if the password will not expire, can be in the past if already expired. If you prefer, you can use passwordmodifiedtimestamp instead.
• Attribute value is NTFS filetime—The number of 100ns ticks since 1st of January 1601 UTC. If you prefer, you can set Unix time or ISO 8601 date and time instead. No other formats are accepted.

<AttributeStatement>
<Attribute
     Name="http://schemas.google.com/saml/2019/passwordexpirationtimestamp">
     <AttributeValue>132253026634083525</AttributeValue>
</Attribute>
</AttributeStatement>

(Optional) Step 6: Enable SAML SSO IdP Redirection

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.

1. Sign in to your Google Admin console.

   Sign in using your administrator account (does not end in @gmail.com).

2. In the Admin console, go to Menu  DevicesChromeSettingsDevice settings.
3. To apply the setting to all devices, leave the top organizational unit selected. Otherwise, select a child organizational unit.
4. Go to Sign-in settings.
5. Click Single sign-on IdP redirection.
6. Select Allow users to go directly to SAML SSO IdP page. For more details, see Set ChromeOS device policies.
7. Click Save. Or, you might click Override for an organizational unit.

   To later restore the inherited value, click Inherit. 

(Optional) Step 7: Username passthrough

You can automatically pass usernames from Google Identity to the 3P IdP to avoid users having to type their username twice.

Before you begin

• This feature is only available to IdPs that allow username handover as part of the SAML query. For details, see Autofill username on SAML IdP login page.
• If you always redirect users to the third-party identity provider (3P IdP) by completing step 7, username passthrough is limited to reauthentication flows. For details, see the SAML single sign-on login frequency or SAML single sign-on unlock frequency settings.

1. Sign in to your Google Admin console.

   Sign in using your administrator account (does not end in @gmail.com).

2. In the Admin console, go to Menu  DevicesChromeSettingsDevice settings.
3. To apply the setting to all devices, leave the top organizational unit selected. Otherwise, select a child organizational unit.
4. Go to Sign-in settings.
5. Click Autofill username on SAML IdP login page.
6. Enter the URL parameter name.
7. Click Save. Or, you might click Override for an organizational unit.

   To later restore the inherited value, click Inherit. 

(Optional) Step 8: Control content on the sign-in and lock screens

When SAML or OpenID Connect single sign-on is used for user authentication, or when configuring network connections with Captive Portals outside of user sessions, you can block or allow URLs on user sign-in and lock screens using the DeviceAuthenticationURLBlocklist and DeviceAuthenticationURLAllowlist policies.

For more details, see Blocked URLs on the sign-in / lock screens and Blocked URL exceptions on the sign-in / lock screens.

1. Sign in to your Google Admin console.

   Sign in using your administrator account (does not end in @gmail.com).

2. In the Admin console, go to Menu  DevicesChromeSettingsDevice settings.
3. To apply the setting to all devices, leave the top organizational unit selected. Otherwise, select a child organizational unit.
4. Go to Sign-in settings.
5. Click Blocked URLs on the sign-in / lock screens.
   1. Specify which URLs to block from the sign-in and lock screens.
   2. Click Save. Or, you might click Override for an organizational unit.

      To later restore the inherited value, click Inherit. 

6. Click Blocked URL exceptions on the sign-in / lock screens.
   1. Specify which URLs to allow from the sign-in and lock screens.
   2. Click Save. Or, you might click Override for an organizational unit.

      To later restore the inherited value, click Inherit. 

(Optional) Step 9: Turn on automatic sign-in screen refresh

If the 3P IdP sign-in page using SAML or OpenID SSO is permanently shown on the sign-in screen, we recommend that you use the automatic sign-in screen refresh. This prevents the online sign-in page from timing out when it’s left idle. We recommend setting the refresh interval to be at least 1 minute shorter than the expiration time of your sign-in page. Read about the Automatic online sign-in screen refresh setting.

1. Sign in to your Google Admin console.

   Sign in using your administrator account (does not end in @gmail.com).

2. To apply the setting to all devices, leave the top organizational unit selected. Otherwise, select a child organizational unit.
3. Go to Sign-in settings.
4. Click Automatic online sign-in screen refresh
5. Enter a value between 5 and 10080 minutes.
6. Click Save. Or, you might click Override for an organizational unit.

   To later restore the inherited value, click Inherit. 

Step 10: Roll out SAML SSO for devices

After testing SAML SSO for 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 Cloud support.

Google and related marks and logos are trademarks of Google LLC. All other company and product names are trademarks of the companies with which they are associated.