Using Chrome device signals
The adapter looks for a specific request header to determine if the request is originating from a Google Chrome Enterprise managed browser to initiate its flow to retrieve device signals from the browser.
Requests from managed Chrome browsers
For requests originating from managed Chrome browsers, the adapter initiates the flow as described in Overview of the SSO flow to retrieve device signals.
The adapter completes the flow successfully if the request originates from a managed browser and the adapter can retrieve device signals for the account that’s configured to work with Google Cloud Platform. Depending on the availability of the attribute in the device signals, the adapter fulfills several core contract attributes, such as:
-
browserVersion -
displayName -
hostname -
macAddresses -
operatingSystem
The core contract attribute deviceTrustEnabled is always set to true after a successful flow.
Requests from non-Chrome browsers, unmanaged Chrome browsers, or incognito windows
For requests originating from non-Chrome browsers, Chrome browsers that aren’t managed, or a Chrome incognito window, the adapter immediately returns a SUCCESS status and only one core contract attribute, deviceTrustEnabled, set to a value of false.
Authentication policy configuration
The authentication policy should typically use the deviceTrustEnabled contract attribute to make decisions related to stepping authentication flow with multi-factor authentication (MFA).
The adapter fails the authentication flow for the following cases:
-
When a request originates from a managed browser that doesn’t correspond to the account setup in the adapter, causing the adapter to not retrieve device signals.
-
When a runtime error occurs, such as a network error invoking the Google APIs. This can result in timeouts and other unexpected errors.
The authentication policy should be configured to handle these cases. For example, the following policy configuration describes a typical use case where:
-
A request coming from a trusted device goes through HTML form adapter authentication only.
-
A request coming from an untrustworthy device goes through HTML form adapter authentication as the first factor followed by MFA authentication as the second factor.
(Click the image to enlarge it.)
