Tag Archives: identity

New APIs to sign out users and control 2-Step Verification

Quick launch summary 

We’re adding two new APIs to the Admin SDK Directory API: 


Sign user out of all sessions 
This new endpoint allows an admin to programmatically sign a user out of all web and device sessions. This can help manage account access when users leave an organization, if a device is lost or misplaced, or if a user forgot to sign out of a shared device. We do not recommend using this to sign users out and force a sign-in periodically; you can explore the Google web session control feature for that use case. 


Turn off 2-Step Verification 
This new endpoint allows an admin to turn 2-Step Verification (2SV) off programmatically. This action also removes all 2SV methods on the account. Note that in some cases, 2SV cannot be turned off for a user due to other policies that may be in effect. For example, a user may be enrolled in the Advanced Protection Program, or “2SV enforced” is turned on; in such cases the API will fail with an appropriate error code and message. 

Note that both of these actions can already be performed via the Admin console. The current launch makes them accessible via API as well so they can be integrated into automated offboarding workflows. 


Getting started 

  • Admins and developers: This feature will be available via the Admin SDK Directory API. Use the API documentation to learn more about the new endpoints to sign users out or turn off 2-Step Verification. 
  • End users: There is no end user setting for this feature. 

Rollout pace  

Availability 

  • Available to all G Suite customers 

Resources 

Security groups help manage groups used for security and access control

What’s changing 

We’re making security groups available in beta. Security groups help you easily regulate, audit, and monitor groups used for permission and access control purposes. They enable admins to: 
  • Apply a label to any existing Google Group to distinguish it from email-list groups. 
  • Provide strong guarantees that: 
    • External groups (owned outside your organization) and non-security groups cannot be added as a member of a security group. 
    • Security labels, once assigned to a group, cannot be removed. 
Soon, you’ll be able to use more granular admin roles to separate administration of security and non-security groups. Keep an eye on the G Suite Updates blog for an announcement when that rolls out. 


Who’s impacted 

Admins and developers 


Why you’d use it 

Groups are used in a variety of ways. This can include groups that help teams communicate and collaborate, as well as groups that control access to important apps and resources. Security groups can help customers manage these categories of groups differently to increase their overall security posture. 

For example, if you have compliance or regulatory requirements for managing access control, you may have set up naming conventions to keep track of which groups were used for this purpose. With security groups, you can now assign a security label to these groups and more easily manage them without having to use workarounds like naming conventions. 


Getting started 

Rollout pace 

  • This feature is available now for all users in beta. 

Availability 

  • Available to all G Suite customers 

Resources 

Context-Aware Access for SAML apps now generally available

Quick launch summary 

In April, we announced a beta which enabled admins to control access to SAML apps based on context. Now, we’re making this feature generally available. 

You can use Context-Aware Access (CAA) to create granular access control policies for pre-integrated SAML apps or custom SAML apps based on attributes including the user, location, device security status, and IP address. This can improve your security posture by reducing the chances that there’s unintended access to specific apps and the data in them. 

See our beta announcement for more details on how the feature works and how you can use it. CAA can be used for SAML apps (policy evaluation on sign-in) that use Google as the identity provider. A third-party identity provider (IdP) can also be used (third-party IdP federates to Google Cloud Identity and Google Cloud Identity federates to SAML apps). Visit our Help Center to see how to set up single sign-on for managed Google Accounts using third-party Identity providers.


Getting started 

  • Admins: This feature will be available by default. Any policies created during the beta will persist when the feature becomes generally available. 
  • End users: No end-user impact until turned on by the admin. 

Rollout pace 

Availability 

  • Available to G Suite Enterprise, G Suite Enterprise for Education, and Cloud Identity Premium customers 
  • Not available to G Suite Basic, G Suite Business, G Suite for Education, G Suite for Nonprofits, G Suite Essentials, and Cloud Identity Free customers 

Resources 

Use service accounts with Google Groups APIs without domain-wide delegation

What’s changing 

Service accounts can now have direct access to Groups APIs without needing domain-wide delegation and admin impersonation. This means you can: 

Who’s impacted 

Admins and developers 


Why it’s important 

Using service accounts with Groups can help provide sufficient data access for business apps and enable the automation of various admin tasks. 

Previously, you had to use domain-wide delegation and admin impersonation to provide service accounts with sufficient data access. This was a cumbersome process, which could result in overly broad privileges for the service account and audit logs that were hard to interpret. 

By enabling direct API access, we’re making it easier to use service accounts to enable critical business apps and processes while making it easier to maintain a strong security and compliance posture. 


Getting started 

Rollout pace 

  • API role assignments: This feature is available now for all users 
  • Admin console roles page updates: Rapid and Scheduled release domains: Gradual rollout (up to 15 days for feature visibility) starting on August 26, 2020 Service account 
  • API access: This feature is available now for all users 

Availability 

  • Available to all G Suite customers 

Resources 

Adding support for service accounts in Google Groups

What’s changing 

We’re adding full support for service accounts in Groups in beta. This builds on our recent announcements of a new Cloud Identity Groups API beta and the ability to use service accounts with Groups APIs without domain-wide delegation. With this launch, you can now: 
  • Add service accounts from primary and secondary domains without turning the “Allow external members in the group” setting on. 
  • See the service account member type on the Groups page and audit logs in the Admin console. 
  • Add, remove, and manage service account membership via the Admin console and Cloud Identity Groups API. 


Who’s impacted 

Admins and developers 


Why it’s important 

Groups are a critical tool for customers to manage their G Suite deployment. Many customers use service accounts with Groups to automate user management, manage migrations, and integrate G Suite with other apps, tools, and services. 

Until now, it was difficult to use service accounts in groups due to limitations in the functionality. This launch fixes many challenges and makes it easier to use service accounts with groups while increasing security and transparency. 



Additional details 

The feature does not affect Admin SDK Group APIs. 



Getting started 



Rollout pace 

  • This feature is available now for all users. 

Availability 

  • Available to all G Suite customers 

Resources 

Profile photo updates: Unified user photos and new admin controls

Quick launch summary 

We’re changing the manner in which user profile photos are displayed across Google products and services, and updating how admins can manage those photos. 

Last year, we removed a photo setting in Gmail that allowed users to set a different profile photo in Gmail than their Google Account. Starting today, users who still have two different profile photos will be migrated to a single profile photo. No action is needed by users, the current Google Account photo will become their only profile photo. This will ensure users are seen and recognized consistently across different products and interfaces. 

We’re also giving admins the ability to set the single Google Account profile photo for users. You can add, replace, or delete an existing profile photo for users through the Admin console or through the Admin SDK Directory API. 

Previously set Google Account profile photos are kept in a user’s Album Archive, available at get.google.com/albumarchive. New profile photos set by users or admins will also be stored here. 

Note that if a user updates their photo, the photo will be visible to everyone, across Google products. If an admin adds a photo to a user’s account, it will only be visible to users within their organization and external users they interact with. Learn more about what information others can see across Google services. 


Getting started 

A user’s Google Account photo will be used for their profile photo 


Rollout pace 

Availability 

  • Available to all G Suite customers 

Resources 

Manage groups programmatically with the Cloud Identity Groups API beta

What’s changing 

We’re launching a new Cloud Identity Groups API. This will enable you to create and manage Google Groups and their memberships for your domain via API. Previously, API support for group management was available only via the Admin SDK and therefore was accessible only to domain admins. With this launch, the APIs can be accessed by admins as well as non-admins. Once you create groups via the API, you can view and manage them through the Google Groups web UI (groups.google.com), through the Admin console, or via the API. 

Using the new API you can: 
  • Create and delete groups 
  • See and update group metadata 
  • Add members to and remove members from a group 
  • Modify member roles within a group 
See our developer documentation for more details on how to use the Cloud Identity Groups API. 


Who’s impacted 

Admins, developers, and end users 


Why you’d use it 

Groups are an important tool to manage communication, access, and security for organizations. Adding the ability to create and manage groups via an API can help make group management more scalable and efficient. 


Additional details 

Available to admins, developers, and end users 
Business teams can create and manage groups they own without being granted admin permissions, preventing them from managing additional, unnecessary groups and saving the admin team time. This allows teams to manage their work more efficiently without creating any security risks from assigning admin permissions when they are only needed for this specific task. 


Getting started 

Rollout pace 

  • This feature is available now for all users in beta. 

Availability 

  • Available to all G Suite customers 

Resources 

Strengthening 2-Step Verification by showing phone prompts to more users

What’s changing 

Starting on July 7, 2020, we will make phone verification prompts the primary 2-Step Verification (2SV) method for all eligible users, unless they are already using security keys as their 2SV method of choice. This means that if you sign in to your Google account and are also signed in on a smartphone, you will be asked to follow phone prompts to verify the login attempt. This will help increase account security while making it easier to sign in.

This won’t apply if you use a security key to protect your account. You’ll also still be able to use other methods (such as a code received by text) by selecting a different method during the phone prompt verification steps.
Phone prompts verify your sign-in attempt via your smartphone 


Who’s impacted 

End users

Why it’s important 

Phone prompts, also known as “on-device prompts,” are more secure than text or voice codes as a form of 2-Step Verification. They’re also easier to use, as they avoid requiring users to manually enter a code received on another device. By making prompts the primary method for more users, we hope to help them take advantage of the additional security without having to manually change settings—though they can still use other methods of 2-Step Verification if they prefer.


Additional details 

How phone prompts work 
After you enter your password to sign in to your Google Account, Google sends a "Trying to sign in?" prompt to every eligible mobile device where you’re signed in. This prompt tells you when and where your password was entered, and then asks you to confirm or block the sign-in attempt by simply tapping your mobile device. You can still select a different verification method during sign-in if one is available on your account. You’ll also stop receiving prompts on a phone if you sign out of that phone. Learn more about phone prompts.

Users with security keys are excluded from this change 
Users will not have prompts as their primary 2SV method in two situations:

  • If an organization enforces the “Only security key” 2-Step Verification option for a user, there will be no change and the user will continue to be required to use security keys. 
  • If a user currently has, or at any point in the future adds, a security key on their account, the security key verification will be presented as the primary method. 

Additionally, if a user doesn’t have 2-Step Verification turned on, this will not apply.


Getting started 



Rollout pace 



Availability 


  • Available to all G Suite customers and users with personal accounts. 

Resources 


Use NFC and USB security keys natively on iOS devices

What’s changing 

We’re making it easier to use security keys with your Google Account on iOS devices. Specifically, we’re enabling native support for the W3C WebAuthn implementation on Apple devices running iOS 13.3 and above. This means you can use a USB or NFC security key directly on an iOS device, without installing the Google Smart Lock app.

Learn more about how you can use security keys on Apple devices on our Security blog.

Who’s impacted 

End users

Why it’s important 

Security keys provide the strongest form of 2-Step Verification (also known as two-factor authentication or 2FA) to help protect your account against phishing, especially when used as part of the Advanced Protection Program for the enterprise. With this launch you can now:

  • Tap a Titan Security Key (all of which have built-in NFC) on the back of your iPhone. 
  • Use any USB security key directly on an iOS device that has a USB port (such as an iPad Pro) or via an Apple Lightning to USB camera adapter on any other device. 
  • Use Bluetooth security keys or your phone’s built-in security key on any iOS device via the Google Smart Lock app. 


We hope this launch makes it easier for iOS users to take advantage of the protection security keys offer. See more about why this matters and how to use it on our Security blog.

Using an NFC security key on iPhone 

Getting started 



Rollout pace 



Availability 


  • Available to all G Suite and Cloud Identity customers, as well as users with personal Google Accounts 

Resources 


Updated Admin console for 2-Step Verification and SSO for SAML controls

Quick launch summary 

We’re making two updates to the Admin console:

New 2-Step Verification (2SV) controls: 
We’re updating the controls you use to configure 2SV in the Admin console. You may notice:

  • A new “2-Step Verification settings” section of the Security page where you can turn 2SV on or off and control other related settings. You can find this at Admin console > Security > 2-Step Verification. 
  • The ability to turn 2SV enrollment on or off for each organizational unit (OU). Previously you could only turn it on or off for the whole domain. Once it’s turned on, additional 2SV policies can be adjusted. 
  • New interfaces which prevent admins accidentally locking themselves out of an account by enforcing 2SV without being enrolled in 2SV. 
  • An updated and streamlined interface. 
The new 2-Step Verification settings section in the Admin console

In the 2SV section you can configure 2-Step Verification enforcement by OU


New section for single sign-on settings for SAML applications 
We’re making some updates to the settings you use to set up single sign-on for SAML applications. You may notice:

  • The settings that apply to all SAML applications when Google is the Identity Provider (IdP) are now in their own section in Security settings at Admin Console > Security > Set up single sign-on (SSO) for SAML applications. 
  • The functionality is not changing but you will find a more streamlined experience for managing certificates and to download IdP metadata. 
The new SSO for SAML settings section in the Admin console

 The new SSO for SAML area where you can control related settings

Getting started 



  • Admins: The new per-OU 2SV enrollment feature will be set to ON at the organization level (root OU) if and only if you had allowed 2SV enrollment for your organization prior to this launch, so that there is no change in behavior for your organization. After the launch, you can now change 2SV enrollment at an OU level. You can also use exception groups for 2SV enrollment settings, similar to how 2SV enforcement settings support them. Visit the Help Center to learn more about how to deploy 2-Step Verification for your organization.
  • End users: There is no end user impact for the feature. 

Rollout pace 



Availability 


  • Available to all G Suite and Cloud Identity customers 

Resources