Tag Archives: Administrative APIs

Identifying app usage in your Google Drive audit logs



If you’re a G Suite admin (or a developer creating apps for admins), it’s important to understand the various applications your company’s employees are using and how they’re accessing them. Today, we’re making that easier by introducing app identification (i.e. originating_app_id) in the Google Drive audit logs within the Admin SDK Reports API.

Now, your apps will be able to determine whether an activity logged was performed by a user in the Drive Android app, Drive iOS app, Google Chrome, or through a variety of other third-party apps that leverage, modify or create files within Google Drive, like Smartsheet or Asana. This will give you a better sense of the apps being used in your organization, as well as the extent and context of that usage.

Note that App IDs that show up in the logs will be numeric. Should you want to retrieve app names, a separate request using the Google Drive REST API is needed. If you already retrieve information through the Drive activity request, you should start seeing the originating_app_ids show up in your logs. Here are a pair of HTTP requests you can use to query this information:

GET 
https://www.googleapis.com/admin/reports/v1/activity/users/userKey

Or
GET 
https://www.googleapis.com/admin/reports/v1/activity/users/all/applications/drive

To learn more about this new feature, take a look at the documentation, then integrate into your code so you and other G Suite admins can gain a better understanding of app usage in your domain(s). We look forward to seeing what you build!

Modifying email signatures with the Gmail API

Originally posted on G Suite Developer blog

Posted by Wesley Chun (@wescpy), Developer Advocate, G Suite

The Gmail API team introduced a new settings feature earlier this year, and today, we're going to explore some of that goodness, showing developers how to update Gmail user settings with the API.

Email continues to be a dominant form of communication, personally and professionally, and our email signature serves as both a lightweight introduction and a business card. It's also a way to slip-in a sprinkling of your personality. Wouldn't it be interesting if you could automatically change your signature whenever you wanted without using the Gmail settings interface every time? That is exactly what our latest video is all about.

If your app has already created a Gmail API service endpoint, say in a variable named GMAIL, and you have the YOUR_EMAIL email address whose signature should be changed as well as the text of the new signature, updating it via the API is as pretty straightforward, as illustrated by this Python call to the GMAIL.users().settings().sendAs().patch() method:

signature = {'signature': '"I heart cats."  ~anonymous'}
GMAIL.users().settings().sendAs().patch(userId='me',
sendAsEmail=YOUR_EMAIL, body=signature).execute()

For more details about the code sample used in the requests above as well as in the video, check out the deepdive post. In addition to email signatures, other settings the API can modify include: filters, forwarding (addresses and auto-forwarding), IMAP and POP settings to control external email access, and the vacation responder. Be aware that while API access to most settings are available for any G Suite Gmail account, a few sensitive operations, such as modifying send-as aliases or forwarding, are restricted to users with domain-wide authority.

Developers interested in using the Gmail API to access email threads and messages instead of settings can check out this other video where we show developers how to search for threads with a minimum number of messages, say to look for the most discussed topics from a mailing list. Regardless of your use-case, you can find out more about the Gmail API in the developer documentation. If you're new to the API, we suggest you start with the overview page which can point you in the right direction!

Be sure to subscribe to the Google Developers channel and check out other episodes in the G Suite Dev Show video series.

Modifying email signatures with the Gmail API

Posted by Wesley Chun (@wescpy), Developer Advocate, G Suite

The Gmail API team introduced a new settings feature earlier this year, and today, we're going to explore some of that goodness, showing developers how to update Gmail user settings with the API.

Email continues to be a dominant form of communication, personally and professionally, and our email signature serves as both a lightweight introduction and a business card. It's also a way to slip-in a sprinkling of your personality. Wouldn't it be interesting if you could automatically change your signature whenever you wanted without using the Gmail settings interface every time? That is exactly what our latest video is all about.

If your app has already created a Gmail API service endpoint, say in a variable named GMAIL, and you have the YOUR_EMAIL email address whose signature should be changed as well as the text of the new signature, updating it via the API is as pretty straightforward, as illustrated by this Python call to the GMAIL.users().settings().sendAs().patch() method:

signature = {'signature': '"I heart cats."  ~anonymous'}
GMAIL.users().settings().sendAs().patch(userId='me',
sendAsEmail=YOUR_EMAIL, body=signature).execute()

For more details about the code sample used in the requests above as well as in the video, check out the deepdive post. In addition to email signatures, other settings the API can modify include: filters, forwarding (addresses and auto-forwarding), IMAP and POP settings to control external email access, and the vacation responder. Be aware that while API access to most settings are available for any G Suite Gmail account, a few sensitive operations, such as modifying send-as aliases or forwarding, are restricted to users with domain-wide authority.

Developers interested in using the Gmail API to access email threads and messages instead of settings can check out this other video where we show developers how to search for threads with a minimum number of messages, say to look for the most discussed topics from a mailing list. Regardless of your use-case, you can find out more about the Gmail API in the developer documentation. If you're new to the API, we suggest you start with the overview page which can point you in the right direction!

Be sure to subscribe to the Google Developers channel and check out other episodes in the G Suite Dev Show video series.

Saying Goodbye to the GData Admin Settings API

Posted by Shashank Gupta, Product Manager, Google Apps for Work and Wesley Chun, Developer Advocate, Google Apps

Back in 2013, we launchedthe Google Apps Admin SDK, and later announced as a result that several outdated Apps Admin APIs would be deprecated and shut down in April 2015. Today, we are continuing this effort of removing older, less-used functionality by announcing the deprecation of the GData Admin Settings API. Some GData API functionality will find a replacement from an Admin SDK counterpart, while other features will be discontinued. The following table summarizes which features will be retained (and where to access replacement functionality) and which won’t:

Admin Settings API

Endpoint

Post-Deprecation Replacement (if any)

General Settings

/defaultLanguage

Customer API

/organizationName

Customer API

/currentNumberOfUsers

no replacement / discontinued

/maximumNumberOfUsers

no replacement / discontinued

Account Settings

/accountInformation/supportPIN

no replacement / discontinued

/accountInformation/customerPIN

no replacement / discontinued

/accountInformation/adminSecondaryEmail

Customer API

/accountInformation/edition

no replacement / discontinued

/accountInformation/creationTime

Customer API

/accountInformation/countryCode

Customer API

Appearance Settings

All endpoints

no replacement / discontinued

Verification Settings

All endpoints

no replacement / discontinued

Single Sign-on (SSO) Settings

All endpoints

replacement API coming soon

Gateway and Routing Settings

All endpoints

no replacement / discontinued

To summarize, the GData Admin Settings API is being deprecated today and will remain operational for one year to give developers time to migrate. This means that on August 16, 2017, this deprecated API will be shut down. At that time, all calls to the API and any features in your applications that depend on it will no longer work. Please migrate as soon as possible.

Google Mobile Management: Introducing Mobile Audit in the Reports API

Posted by Sumit Chatterjee, Program Manager, Google Mobile Management and Wesley Chun, Developer Advocate, Google Apps

As security on mobile devices becomes increasingly important, we want to give Google Apps administrators the visibility to monitor key activities occurring on managed devices in their domain. With that in mind, today we are launching Mobile Audit for Google Apps Unlimited users, which audits activities on iOS and Android devices (using the native iOS Sync and Android Sync protocols) managed by Google Mobile Management. Examples of activities that are recorded include: operating system updates, device settings changes, and mobile application installs, updates and removals.

Google Apps Administrators can also go to the Reports page in the Admin console to see all the Mobile Audit events. Below is an example of what this page looks like querying one user’s activity, including newly registered devices:

Mobile Audit report and alert creation for a single user in the Admin console

As part of this launch, we are excited to make all Mobile Audit events available programmatically through the Admin SDK Reports API via Mobile Audit Activity Events. The Admin SDK is accessible through its REST API or Google Apps Script. With this new feature, administrators will be able to query all of the Mobile Audit information by user, by device, or by event, as well as verify that all of your deployed devices are running the latest security updates. You can even send this information to an asset management system to track all of your mobile inventory.

For example, if we wanted to download all of the newly registered devices, you could make a call like this to the API (via Google Apps Script):


AdminReports.Activities.list('all', 'mobile', {
eventName: "DEVICE_REGISTER_UNREGISTER_EVENT",
filters: "ACCOUNT_STATE==REGISTERED",
maxResults: 1000
});

Once you have the response from the API, you could easily parse through that data, including device models, serial numbers, user email addresses, and any other relevant information to help you track your inventory.

A more critical use case that mobile administrators have been asking for is a way to take proactive actions on devices without requiring manual intervention. For example, a mobile administrator may want to automatically block a device when something suspicious is detected. This new feature enables admins to write simple apps that do just that.

Using the Mobile Audit Activity Events in the Reports API and the Mobile Devices component of the Directory API, administrators can create scheduled scripts to check for devices that are reporting suspicious activity, and then take actions on those devices.

The Apps Script snippet below returns results if there are any mobile audit events for suspicious activity:

var response = AdminReports.Activities.list('all', 'mobile', {
eventName: "SUSPICIOUS_ACTIVITY_EVENT",
maxResults: 1000
});

If there are results, the code below shows you how to retrieve the unique Google identifier for those devices, via the “RESOURCE_ID” parameter. Note that this snippet only assumes a single device reporting suspicious activity—you’ll need to tweak the code to support more than one.

var parameters = response.items[0].events[0].parameters;
var resourceId;
for (i = 0; i < parameters.length; i++) {
if (parameters[i].name == ‘RESOURCE_ID’) {
resourceId = parameters[i].value;
break;
}
}

Now the Directory API can be invoked to block the device that corresponds with the above unique identifier using this Apps Script snippet:

AdminDirectory.Mobiledevices.action('my_customer', resourceId, {
action: "block"
});

We are really excited to see what uses you have for Mobile Audit in the Reports API. For more information and to get started, please see the Developer Guide, reference documentation, and the Help Center. (NOTE: Again, this feature is available only to our customers with users on the Google Apps Unlimited license.)

Saying goodbye to OAuth 1.0 (2LO)

Originally posted on Google Apps Developers Blog

Posted by Vartika Agarwal, Technical Program Manager, Identity & Authentication, and Wesley Chun, Developer Advocate, Google

As we indicated several years ago, we are moving away from the OAuth 1.0 protocol in order to focus our support on the current OAuth standard, OAuth 2.0, which increases security and reduces complexity for developers. OAuth 1.0 (3LO)1 was shut down on April 20, 2015. During this final phase, we will be shutting down OAuth 1.0 (2LO) on October 20, 2016. The easiest way to migrate to the new standard is to use OAuth 2.0 service accounts with domain-wide delegation.

If the migration for applications using these deprecated protocols is not completed before the deadline, those applications will experience an outage in their ability to connect with Google, possibly including the ability to sign-in, until the migration to a supported protocol occurs. To avoid any interruptions in service for your end-users, it is critical that you work to migrate your application(s) prior to the shutdown date.

With this step, we continue to move away from legacy authentication/authorization protocols, focusing our support on modern open standards that enhance the security of Google accounts and that are generally easier for developers to integrate with. If you have any technical questions about migrating your application, please post them to Stack Overflow under the tag google-oauth.


1 3LO stands for 3-legged OAuth: there's an end-user that provides consent. In contrast, 2-legged (2LO) doesn’t involve an end-user and corresponds to enterprise authorization scenarios such as enforcing organization-wide policy control access.

Saying goodbye to OAuth 1.0 (2LO)

Posted by Vartika Agarwal, Technical Program Manager, Identity & Authentication, and Wesley Chun, Developer Advocate, Google

As we indicated several years ago, we are moving away from the OAuth 1.0 protocol in order to focus our support on the current OAuth standard, OAuth 2.0, which increases security and reduces complexity for developers. OAuth 1.0 (3LO)1 was shut down on April 20, 2015. During this final phase, we will be shutting down OAuth 1.0 (2LO) on October 20, 2016. The easiest way to migrate to the new standard is to use OAuth 2.0 service accounts with domain-wide delegation.

If the migration for applications using these deprecated protocols is not completed before the deadline, those applications will experience an outage in their ability to connect with Google, possibly including the ability to sign-in, until the migration to a supported protocol occurs. To avoid any interruptions in service for your end-users, it is critical that you work to migrate your application(s) prior to the shutdown date.

With this step, we continue to move away from legacy authentication/authorization protocols, focusing our support on modern open standards that enhance the security of Google accounts and that are generally easier for developers to integrate with. If you have any technical questions about migrating your application, please post them to Stack Overflow under the tag google-oauth.


1 3LO stands for 3-legged OAuth: there's an end-user that provides consent. In contrast, 2-legged (2LO) doesn’t involve an end-user and corresponds to enterprise authorization scenarios such as enforcing organization-wide policy control access.

Deprecating ScriptDB and Domain Service in Apps Script

In the last few months, we've added a number of new features to Google Apps Script, including add-ons for Sheets and Docs and 7 new advanced services.

We're eager to maintain that momentum — focusing on new features that help you do more with Google Apps. As a result, we're deprecating two Apps Script services for which good replacements exist elsewhere: ScriptDB (a NoSQL database that has been marked as experimental since it was introduced) and the Domain service (which encapsulates the GroupsManager, NicknameManager, and UserManager global objects).

Both ScriptDB and the Domain service will be turned off on November 20, 2014.

Before then, you'll need to port any ScriptDB projects to another data store, like Google Cloud SQL or a third-party NoSQL database. We've created a migration guide that explains how to export your data from ScriptDB and suggests a few alternate data stores. We have also improved the documentation for connecting to external databases through JDBC to make it a little easier for you to set up Cloud SQL with Apps Script.

The Domain service, which only Google Apps domain administrators can use, is replaced by the recently added Admin SDK Directory and Admin SDK Reports advanced services. Those advanced services also provide many new features that the Domain service does not — like managing users' devices, OAuth tokens, and application-specific passwords — so we expect that you'll prefer using them in the future.


Saurabh Gupta   profile | twitter | blog

As the product manager for Google Apps Script, Saurabh is responsible for Apps Script’s overall vision and direction.

Introducing push notifications and structured user search in the Admin SDK

Since we launched the Admin SDK in May 2013, we’ve been constantly improving it based on your feedback and feature requests. Our first API updates of 2014 bring some features at the top of your requests: push notifications for users, push notifications for activities, and structured user search.


Push notifications for users

Tired of polling user resources to detect changes? With push notifications for users, you can watch for changes to user resources and receive notifications from the Directory API whenever a watched user resource changes.

Check out our user notifications developer guide to learn how to improve the performances of your application by eliminating the extra network and compute costs involved with polling user resources.


Push notifications for activities

Do you want to be notified when changes to a certain document occur or specific events such as the change of a user’s password happen? With push notifications for activities you can watch for changes to activities resources, and receive notifications from the Reports API whenever a watched activity resource changes.

Check out our activities notifications developer guide to learn how to receive notifications for the activities of your interest.


Structured user search

Do you want to know which users in your domain are members of a certain organization, or which users have a common manager in their reporting chain? The new query parameter we’ve just added to the users.list method of the Directory API allows you to perform rich queries over most attributes from the user profile.

For example, you can now retrieve all the users in the Human Resources org by using the query:

orgName='Human Resources'
Or you can retrieve all the users with [email protected] in their reporting chain by using the query:
manager='[email protected]'

Check out our user search developer guide for a more comprehensive guide on how to build your queries and more examples of what you can do.

Silvano Luciani  

Silvano is a Developer Programs Engineer on Google's Admin SDK. Before joining Google in 2011, he has worked in Finland, Italy, Spain and the UK, writing web based configuration management tools for ISPs, social networks, web based training materials, e-commerce apps and more.

New security management features for domain users with the Admin SDK

We launched the Admin SDK in May as a new way for developers to build customized administrative tools for organizations that use Google Apps. A top priority for most administrators is keeping their users safe. Today, we're adding new security management features to the Directory API to help administrators manage:

These new utilities allow Google Apps administrators to programmatically manage end-user access to third party applications, and enable third party developers to build new security management features in their applications.

As an example, FlashPanel, a popular tool used by Google Apps administrators, is using these new features to allow domain admins to review installed applications and manage or revoke access to them. The Apps Explorer in FlashPanel allows admins to see which are the most installed apps in his domain or use a filter to review applications by type of permissions (Drive, GMail, etc). It also allows admins to review the number of users who have granted access to a particular application.

The screenshot below shows an example of FlashPanel’s customized view of third-party application installs.

In FlashPanel’s integration, admins have the power to whitelist or blacklist apps, as shown below.

The Directory API now also provides the ability to manage admin notifications that are delivered to the Admin Console. Currently, admins receive notifications for events that affect their domains such as users approaching their storage limits or monthly bills that are due. Now you can use the API to list notifications, update their read status, or pull them into custom tools.

If you are interested in using these new endpoints, please refer to the Directory API documentation.

Ajay Guwalani  

Ajay Guwalani is Product Manager on Google Apps Admin APIs. His current focus is to build next generation admin APIs to make enterprise developers and admins happy.