Kloudless Blog

Tutorials, case studies and how-tos from our experts

Accessing org-wide data using Admin Accounts and user impersonation

API Explorer. Click on ‘Connect Admin Account”, select a service, and follow the steps to grant access. Once completed, you can try out some of the cases below!

Organization accounts with multiple users

Some upstream services have the concept of user-specific data. For example, an Office 365 tenant could have several users, each of whom have their own personal OneDrive for Business drive in addition to a large shared group or SharePoint site to collaborate in. In order to access a connected account as an individual user, Kloudless allows API requests to use the X-Kloudless-As-User header, which identifies the user whose data is being accessed within a specific Kloudless account. Use the Team API to find the IDs of the different users to impersonate within an admin account. The endpoint to list all team members will provide their IDs for use with the X-Kloudless-As-User header (docs). Using this endpoint with an admin account will retrieve more information about the team’s users. Examples of upstream services that use this structure are box, dropbox, gdrive, and onedrivebiz.

Organization accounts with shared data

For services where there is no concept of user-specific data, all data is already available to admin users. As such, no additional steps need to be taken to access the data. Services where this is the case include s3, sharepoint, and egnyte. Let’s take a closer look at how this might affect API calls as an administrator for the different upstream services.

Example API Requests

We’ll start off with an upstream service that has user-specific data. Take a look at the following curl request asking for information about the contents of a user’s root folder within an account connected by an administrator (docs).

This request (assuming you have admin access correctly configured on your upstream service) will successfully return some data. However, if you wanted organization-wide data, you would quickly realize you are only seeing the files and folders that belong specifically to that administrator. Let’s add that header we mentioned earlier, X-Kloudless-As-User, along with a user ID that belongs to a user in the organization.

By including that additional header, we are now able to access data that belongs to the user. The admin user can transform that data as needed. To access other users’ data, that admin can utilize the Team API endpoint to return information on the various team members, and thus access data as needed. This is how impersonation is used as an administrator to manage an organization’s data. Next, let’s a look at a service where all data is already available to admin users. We’ll look at how they interact with Kloudless API calls. The quickest way to see if a given upstream service utilizes impersonation is by either checking our docs or making a query with the impersonation header, X-Kloudless-As-User.

This will return an informative 501 error message, “SharePoint Online users cannot be impersonated”. If you see this message, try removing the added header used for impersonation:

The returned information will include all data that the Kloudless user has access to. As this is an admin account for the upstream service, all data will be accessible.

Next Steps

Your application can now make API requests as usual on behalf of each user in an organization. Check out our blog post on configuring OAuth keys for more information on how to configure your own OAuth credentials to authenticate admin accounts. Feel free to reach out to us with any questions or feedback at support@kloudless.com!

Published By

Chris Prochnow