The screen is also not shown on devices running Chrome OS.We want to be clear that this change to sign-in does not mean Chrome sync gets turned on. *This won't impact individuals who sign in to G Suite services directly and those who use G Suite or Cloud Identity as their identity provider. This header can be set in Chrome via the AllowedDomainsForApps group policy. Users in those domains won’t see this additional screen, as we assume those accounts are trusted by your users. If you wish to disable the new screen for your organization, you can use the X-GoogApps-AllowedDomains HTTP header to identify specific domains whose users can access Google services. This new screen adds that protection and reduces the probability that attackers successfully abuse SAML SSO to sign users in to malicious accounts. This consistency will make it easier for signed-in G Suite users to take advantage of native Chrome browser features, but it requires additional protection during authentication.
This new security feature is part of a larger project to create a consistent identity across Google web services (like Gmail) and native Chrome browser services (like Chrome Sync).
To protect Chrome users, we’ve added this extra protection.
Today, this can be done via SAML single sign-on (SSO), because it doesn’t require a user interaction to complete a sign-in. via a phishing campaign) into clicking a link that would instantly and silently sign them in to a Google Account the attacker controls. This new screen is intended to prevent would-be attackers from tricking a user (e.g. We’re working on ways to make the feature even more context-aware in the future, meaning your users should see the screen less and less over time. To minimize disruption for the user, this feature will only be shown once per account per device.
0 kommentar(er)
