Tag Archives: identity

Google Workspace Updates Weekly Recap – May 13, 2022

New updates 

Unless otherwise indicated, the features below are fully launched or in the process of rolling out (rollouts should take no more than 15 business days to complete), launching to both Rapid and Scheduled Release at the same time (if not, each stage of rollout should take no more than 15 business days to complete), and available to all legacy Google Workspace and G Suite customers. 


New idle status in Google Chat 
In Google Chat on web and Chat in Gmail, you'll see an orange clock badge for users that were recently active in Chat, but aren't currently active. We hope this makes it easier to determine the best time to connect with your colleagues. Visit the Help Center to learn more about availability statuses in Google Chat. 





Changes to the default Host Management controls in Google Meet for users with personal accounts 
The default setting for Host Management controls is changing for users with personal Google accounts. Previously, Host Management controls were ON by default — going forward, this setting will be OFF by default for new meetings. There are no changes to the behavior for Google Workspace customers or Google Workspace Individual users.



Previous announcements


The announcements below were published on the Workspace Updates blog earlier this week. Please refer to the original blog posts for complete details.


Improved user interface for sharing your working location in Google Calendar
This update improves the working location feature by offering the same functionality for easily entering and updating location information in a more compact format that uses screen space more efficiently. | Learn more here and here. 

Available to Google Workspace Business Standard, Business Plus, Enterprise Standard, Enterprise Plus, Education Plus, and Nonprofits, as well as G Suite Business customers. 


Easily search for Google Meet content in Google Drive
In Google Drive, you can now use app:”Google Meet” to easily find and organize Meet content such as Meet recordings, meeting transcripts, and more. | Learn more.


Import existing custom themes to new Google Sites
You can now import a custom theme from one new Google Site to another. | Learn more.


Create Spaces and Add Members with the Google Chat API, available in Developer Preview
Using the Google Chat API, you can now programmatically create new Spaces and add members to those Spaces. This functionality is available in preview – developers can apply for access through our Google Workspace Developer Preview Program. | Learn more.


Require email verification to book appointments in Google Calendar
When using appointment scheduling in Google Calendar, you can now opt to have users verify their email before booking an appointment. When enabled, the user must be signed into a Google account or validate their email address using a PIN code to complete the booking. | Learn more.

Available to Google Workspace Business Standard, Business Plus, Enterprise Standard, Enterprise Plus, Education Fundamentals, Education Standard, Education Plus, the Teaching and Learning Upgrade, and Nonprofits customers.


New delegated VirusTotal privilege in the Alert Center
In 2021, we announced an integration between the Alert Center and VirusTotal. At that time, any admin who had the Alert Center privilege could access all VirusTotal reports. Now, we’ve added the ability for admins to control who can view VirusTotal reports. | Learn more.

Available for Google Workspace Business Plus, Enterprise Standard, Enterprise Plus, Education Standard and Education Plus.


Set up SSO profiles for multiple third-party identity providers with the Multi-IdP SSO beta launch
You can further customize authentication by setting up single sign-on (SSO) profiles for multiple identity providers and then configuring authentication for each group or OU. This feature is available beginning today as an open beta, which means you can use it without enrolling in a specific beta program. | Learn more.


For a recap of announcements in the past six months, check out What’s new in Google Workspace (recent releases).

Set up SSO profiles for multiple third-party identity providers with the Multi-IdP SSO beta launch

What’s changing 

For over a decade, we have given admins the ability to configure authentication through a third-party identity provider . In 2021, we expanded this capability by making it possible to choose between third-party identity provider or Google authentication for specific groups or organizational units (OUs). 


Now, you can further customize authentication by setting up single sign-on (SSO) profiles for multiple identity providers and then configuring authentication for each group or OU. This feature is available beginning today as an open beta, which means you can use it without enrolling in a specific beta program.


You can now set up SSO profiles for multiple third-party identity providers




Who’s impacted


Admins

Why you’d use it

Currently, you can configure SSO with a third-party identity provider to apply to your entire domain and then require a subset of your users, such as vendors or contractors, to authenticate with Google instead. However, if you have more than one identity provider, you might require greater customization of authentication options. For example, your company might be migrating from one provider to another, or it might have acquired another company that uses a different provider.


The Multi-IdP SSO beta lets you set up SSO profiles for each of your third-party identity providers, giving you the flexibility to specify the authentication method for various users in your organization as needed.

Getting started

  • Admins: In the Admin console, navigate to Security > Settings > Set up single sign-on (SSO) with a third party IdP > Manage SSO Profile assignments. Visit the Help Center to learn more about setting up SSO for your organization.


Go to the Security settings to set up SSO profiles for third-party identity providers

  • End users: There is no end user setting for this feature.

Rollout pace

  • This feature is available now for all users.


Availability

  • Available to Google Workspace Business Starter, Business Standard, Business Plus, Enterprise Essentials, Enterprise Standard, Enterprise Plus, Education Fundamentals, Education Plus, Frontline, and Nonprofits, as well as legacy G Suite Basic and Business customers
  • Available to all Cloud Identity customers
  • ​​Not available to Google Workspace Essentials customers
  • Not available to users with personal Google Accounts

Resources

Making Google OAuth interactions safer by using more secure OAuth flows

Posted by Vikrant Rana, Product Manager and Badi Azad, Group Product Manager, Google

At Google, we constantly strive to provide safer ways for users to sign-in and share their Google account data with third-party applications. In the spirit of that work, we will be rolling out a set of protections against phishing and app impersonation attacks during the OAuth interactions.

The Google sign-in and authorization flows are powered by the Google OAuth platform and over the years we have developed and supported a number of ways for app developers to integrate with supported OAuth flows. With the goal of keeping users safer online, we will end support for two legacy flows and will require developers to migrate to alternative implementation methods that offer greater protections.

To ensure a smooth transition and avoid any service interruption we will give ample time to implement and meet the compliance dates which are specified below. We will share further updates on this rollout via email so please make sure your support email address is up to date in project settings on the Google API console.

Loopback IP address flow will be disallowed for native iOS, Android and Chrome OAuth client types

The Loopback IP address flow is vulnerable to man in the middle attack where a malicious app, accessing the same loopback interface on some operating systems, may intercept the OAuth response and gain access to the authorization code. We intend to remove this threat vector by disallowing this flow for iOS, Android and Chrome app OAuth client types. The existing clients will be able to migrate to more secure implementation methods. New clients will be unable to use this flow starting on March 14, 2022.

What do I need to do

Determine if your app is using the Loopback IP address flow

You can inspect your app code or the outgoing network call (in case your app is using an OAuth library) to determine if the Google OAuth authorization request your app is making has the following values for “redirect_uri” parameter.

redirect_uri=http://127.0.0.1:port or http://[::1]:port">http://[::1]:port or

http://localhost:port

Migrate to an alternative flow

If your app is using the Loopback IP address method you need to migrate to another method which is more secure by default. Please consider the following alternative methods for migration.

Key dates for compliance

  • Mar 14, 2022 - new OAuth usage will be blocked for the Loopback IP address flow
  • Aug 1, 2022 - a user-facing warning message may be displayed to non-compliant OAuth requests one month before the compliance date
  • Aug 31, 2022 - the Loopback IP address flow is blocked for existing clients

OAuth out-of-band (oob) flow will be deprecated

OAuth out-of-band (OOB) is a legacy flow developed to support native clients which do not have a redirect URI like web apps to accept the credentials after a user approves an OAuth consent request. The OOB flow poses a remote phishing risk and clients must migrate to an alternative method to protect against this vulnerability. New clients will be unable to use this flow starting on Feb 28, 2022.

What do I need to do

Determine if your app is using the OOB flow

You can inspect your app code or the outgoing network call (in case your app is using an OAuth library) to determine if the Google OAuth authorization request your app is making has the following values for “redirect_uri” parameter.

redirect_uri=urn:ietf:wg:oauth:2.0:oob or urn:ietf:wg:oauth:2.0:oob:auto or oob

Migrate to an alternative flow

If your app is using the OOB method you need to migrate to another method which is more secure by default. Please consider the following alternative methods for migration.

Key dates for compliance

  • Feb 28, 2022 - new OAuth usage will be blocked for the OOB flow
  • Sep 5, 2022 - a user-facing warning message may be displayed to non-compliant OAuth requests
  • Oct 3, 2022 - the OOB flow is deprecated for existing clients

User-facing warning message

A user-facing warning message may be displayed for non-compliant requests one month before the aforementioned OAuth methods are due to be blocked. The message will convey to the users that the app may be blocked soon while displaying the support email that you have registered in the OAuth consent screen in Google API Console.

[Sample user-facing warning]

The developers can acknowledge the user-facing warning message and suppress it by passing a query parameter in the authorization call as shown below.

  • Go to the code in your app where you send requests to Google's OAuth 2.0 Authorization Endpoint.
  • Add a parameter with a value of the enforcement date
    • For OOB: Add an ack_oob_shutdown parameter with a value of the enforcement date: 2022-10-03. Example: ack_oob_shutdown=2022-10-03
    • For Loopback IP address: Add an ack_loopback_shutdown parameter with a value of the enforcement date: 2022-08-31. Example: ack_loopback_shutdown=2022-08-31

User-facing error message

If an app is not updated to meet compliance by the required date the authorization requests will be blocked and users may encounter an invalid request error screen (sample shown below).

[Sample user-facing error]

Making Google OAuth interactions safer by using more secure OAuth flows

Posted by Vikrant Rana, Product Manager and Badi Azad, Group Product Manager, Google

At Google, we constantly strive to provide safer ways for users to sign-in and share their Google account data with third-party applications. In the spirit of that work, we will be rolling out a set of protections against phishing and app impersonation attacks during the OAuth interactions.

The Google sign-in and authorization flows are powered by the Google OAuth platform and over the years we have developed and supported a number of ways for app developers to integrate with supported OAuth flows. With the goal of keeping users safer online, we will end support for two legacy flows and will require developers to migrate to alternative implementation methods that offer greater protections.

To ensure a smooth transition and avoid any service interruption we will give ample time to implement and meet the compliance dates which are specified below. We will share further updates on this rollout via email so please make sure your support email address is up to date in project settings on the Google API console.

Loopback IP address flow will be disallowed for native iOS, Android and Chrome OAuth client types

The Loopback IP address flow is vulnerable to man in the middle attack where a malicious app, accessing the same loopback interface on some operating systems, may intercept the OAuth response and gain access to the authorization code. We intend to remove this threat vector by disallowing this flow for iOS, Android and Chrome app OAuth client types. The existing clients will be able to migrate to more secure implementation methods. New clients will be unable to use this flow starting on March 14, 2022.

What do I need to do

Determine if your app is using the Loopback IP address flow

You can inspect your app code or the outgoing network call (in case your app is using an OAuth library) to determine if the Google OAuth authorization request your app is making has the following values for “redirect_uri” parameter.

redirect_uri=http://127.0.0.1:port or http://[::1]:port">http://[::1]:port or

http://localhost:port

Migrate to an alternative flow

If your app is using the Loopback IP address method you need to migrate to another method which is more secure by default. Please consider the following alternative methods for migration.

Key dates for compliance

  • Mar 14, 2022 - new OAuth usage will be blocked for the Loopback IP address flow
  • Aug 1, 2022 - a user-facing warning message may be displayed to non-compliant OAuth requests one month before the compliance date
  • Aug 31, 2022 - the Loopback IP address flow is blocked for existing clients

OAuth out-of-band (oob) flow will be deprecated

OAuth out-of-band (OOB) is a legacy flow developed to support native clients which do not have a redirect URI like web apps to accept the credentials after a user approves an OAuth consent request. The OOB flow poses a remote phishing risk and clients must migrate to an alternative method to protect against this vulnerability. New clients will be unable to use this flow starting on Feb 28, 2022.

What do I need to do

Determine if your app is using the OOB flow

You can inspect your app code or the outgoing network call (in case your app is using an OAuth library) to determine if the Google OAuth authorization request your app is making has the following values for “redirect_uri” parameter.

redirect_uri=urn:ietf:wg:oauth:2.0:oob or urn:ietf:wg:oauth:2.0:oob:auto or oob

Migrate to an alternative flow

If your app is using the OOB method you need to migrate to another method which is more secure by default. Please consider the following alternative methods for migration.

Key dates for compliance

  • Feb 28, 2022 - new OAuth usage will be blocked for the OOB flow
  • Sep 5, 2022 - a user-facing warning message may be displayed to non-compliant OAuth requests
  • Oct 3, 2022 - the OOB flow is deprecated for existing clients

User-facing warning message

A user-facing warning message may be displayed for non-compliant requests one month before the aforementioned OAuth methods are due to be blocked. The message will convey to the users that the app may be blocked soon while displaying the support email that you have registered in the OAuth consent screen in Google API Console.

[Sample user-facing warning]

The developers can acknowledge the user-facing warning message and suppress it by passing a query parameter in the authorization call as shown below.

  • Go to the code in your app where you send requests to Google's OAuth 2.0 Authorization Endpoint.
  • Add a parameter with a value of the enforcement date
    • For OOB: Add an ack_oob_shutdown parameter with a value of the enforcement date: 2022-10-03. Example: ack_oob_shutdown=2022-10-03
    • For Loopback IP address: Add an ack_loopback_shutdown parameter with a value of the enforcement date: 2022-08-31. Example: ack_loopback_shutdown=2022-08-31

User-facing error message

If an app is not updated to meet compliance by the required date the authorization requests will be blocked and users may encounter an invalid request error screen (sample shown below).

[Sample user-facing error]

Google Workspace Updates Weekly Recap – January 7, 2022

New updates 

Unless otherwise indicated, the features below are fully launched or in the process of rolling out (rollouts should take no more than 15 business days to complete), launching to both Rapid and Scheduled Release at the same time (if not, each stage of rollout should take no more than 15 business days to complete), and available to all Google Workspace and G Suite customers. 



PPTX file limit increase in Google Slides 
You can now import PPTX files up to 300MB into Google Slides using Office Editing mode — previously, 100MB was the maximum. Once imported, you can save back your edits to the underlying PPTX file. | Available to all Google Workspace customers and users with personal Google accounts. | Learn more.



Previous announcements 


The announcements below were published on the Workspace Updates blog earlier this week. Please refer to the original blog posts for complete details. 



Use a new enterprise certificate condition to set context-aware access rules for company-managed devices 
When configuring context-aware access rules, you can now use a new signal to determine whether a device is company-owned. | Available to Google Workspace Enterprise Standard, Enterprise Plus, Education Standard, Education Plus, and Cloud Identity Premium customers. | Learn more. 



For a recap of announcements in the past six months, check out What’s new in Google Workspace (recent releases).

Use a new enterprise certificate condition to set context-aware access rules for company-managed devices

Quick launch summary 

When configuring context-aware access rules, you can now use a new signal to determine whether a device is company-owned. By using new enterprise certificates as an alternative context-aware signal to determine if a device is a company-managed asset, you can set more specific context-aware policies that are appropriate based on the trustworthiness of the device. 
admin console screen to configure context-aware access rules
The Admin console screen to configure context-aware access rules using enterprise certificate condition


Getting started 

Rollout pace 

  • This feature is now available for all eligible users. 

Availability 

  • Available to Google Workspace Enterprise Standard, Enterprise Plus, Education Standard, Education Plus, and Cloud Identity Premium customers 
  • Not available to Google Workspace Essentials, Business Starter, Business Standard, Business Plus, Enterprise Essentials, Education Fundamentals, Frontline, and Nonprofits, as well as G Suite Basic and Business, and Cloud Identity Free customers 

Resources 

Making dynamic groups more powerful with custom user attributes and OrgUnit queries

What’s changing 

Google Groups are a convenient way for Workspaces users to collaborate and a powerful tool for admins to apply consistent security and access policies to sets of users or devices. Dynamic groups further enhance this functionality by allowing group membership to be automatically updated based on parameters such as location, department, or job title. 

Today we are further extending the functionality of dynamic groups in two important ways: 
  • First, dynamic groups can now be defined by querying custom user attributes. This functionality is available as an open beta (no sign up required). 
  • Second, dynamic groups can also be defined based on users’ membership in Organizational Units (OUs). This feature is now generally available. 

Who’s impacted 

Admins only 


Why you’d use it 

Dynamic groups can be used for email distribution lists, access control, group based policy, and more. Compared to regular Google Groups they have the added benefit that memberships are automatically kept up-to-date. Automating membership management increases security, reduces errors, and alleviates user frustration while minimizing the burden on admins. 

These new features expand the utility of dynamic groups for organizations that take advantage of custom user attributes and organizational units. They can further tailor dynamic groups to meet the specific needs of their organization. For example these organizations could now: 
  • Create a dynamic group for all users of a subsidiary (an organizational unit) based in a particular city or state. 
  • Create a dynamic group with all users with a custom attribute of a “job_skill” or “speciality”. 

Getting started 

  • Admins: To take advantage of this new dynamic group functionality, you will need to have already defined custom user fields or organizational units. 
    • Once this is in place you can test membership queries and then create / update dynamic groups to take advantage of them. 
      • To query a customer attribute “EmployeeNumber” (based on this sample schema): user.custom_schemas.employmentData.EmployeeNumber == '123456789' 
      • To query all direct members of an organizational unit: user.org_unit_id==orgUnitId('03ph8a2z1enx4lx') 
      • To query all direct and indirect members of an organizational unit: user.org_units.exists(org_unit, org_unit.org_unit_id==orgUnitId('03ph8a2z1khexns')) 
  • End users: Not available to end users. 

Rollout pace 

  • Custom user attribute queries are available now for all users in open beta (no sign up required) 
  • Organizational unit based dynamic group queries are now generally available for all users. 

Availability 

  • Available to Google Workspace Enterprise Standard, Enterprise Plus, and Education Plus customers 
  • Not available to Google Workspace Essentials, Business Starter, Business Standard, Business Plus, Enterprise Essentials, Education Fundamentals, Frontline, and Nonprofits, as well as G Suite Basic and Business customers 

Resources 

Set user language programmatically with the Directory API

Quick launch summary 

With this launch, you can use Google Workspace Admin SDK Directory API to customize a per user language preference via the user create/update flow. 

Previously, the AdminSDK only allowed one customer level language setting that applied to all users, which could then be changed individually via the Admin console, or by the user. We hope this will make it easier to set up and manage your users at scale. 


Getting started 

Rollout pace 

Availability 

  • Available to all Google Workspace customers, as well as G Suite Basic and Business customers 

Resources 

Assign SSO profile to organizational units or groups with the SAML Partial SSO feature, now generally available

What’s changing

Earlier this year, we announced a beta for assigning SSO profiles to organizational units or groups. This feature is now generally available and allows admins to specify groups or organizational units (OUs) to authenticate a subset of your users using Google.

Who’s impacted

Admins

Why it’s important

Currently, when you configure SSO with a third-party identity provider, the setting applies to your entire domain. However, there are some instances where you may want a subset of your users, such as vendors or contractors, to authenticate with Google instead. The Partial SSO feature gives you the flexibility to specify the authentication method for various users in your organization as needed.


Getting started



  • End users: No action required.

Rollout pace


Availability

  • Available to Google Workspace Business Starter, Business Standard, Business Plus, Enterprise Essentials, Enterprise Standard, Enterprise Plus, Education Fundamentals, Education Plus, Frontline, and Nonprofits, as well as G Suite Basic and Business customers
  • Available to all Cloud Identity customers
  • Not available to Google Workspace Essentials customers

Resources