Admin access to user Google Drive files from installed application with Oauth2 - c#

I'm writing a set of Powershell Cmdlets that allow a user to run admin functions on their domain. Using gData I have been able to do provisioning calls to create new users, list groups and other things of that nature. When trying to list another user's documents (as admin) I hit a roadblock with the DocsList api, so I turned to the Google Drive api instead.
I've since been able to get the Drive API working and have a Cmdlet running based on their QuickStart for DotNet and File List Example. However, I can't seem to figure out how to make it list docs for another user. Everything I've found so far seems to point to the use of Service Accounts for delegation or using the old DocList api instead which is depreciated in favor of the Drive API anyways.
My problem is the Service Accounts seem to be an alternative to the Installed Application, not something I can use at the same time. Or, if I were able to get it working I would have to have each user create their own project and service account, if I'm understanding things.
How can I do this without inconveniencing the users? They've already authenticated themselves as admins, I don't understand why they have to create an API project and service account to achieve the same thing. Would I create a single service account for my API Project? If so, how do I handle the public key it generates and needs access to? That doesn't seem very safe if I'm throwing around the key file.

You can impersonate a user only with service accounts. Once you configure your service account for domain-wide authority, you can make requests with your administrator account as you mention. But, I'm not sure Google Apps allow multiple administrator accounts or not. If they do, all you need is setup a single project and a single service account.


How to programatically register an Azure AD application without tenant ID?

I read these threads but am not really satisfied with the answers:
How to add application to Azure AD programmatically?
How to add application to Azure AD programmatically without having any initial clientId registered?
Adding Applications programmatically in Azure AD using Client Credentials Flow
I think I have a scenario that currently is not supported.
We are building an application that consolidates info about a customer's on-premise infrastructure and cloud environment in a database. It should also gather info about e.g. Office 365 users and subscriptions. Here's the customer scenario:
Download and install the app on-premise.
Configure data sources (similarly to the Inventory and Assessment Wizard in MapToolkit). Also point the app to Office 365 subscription(s) at this point.
Run the app to gather asset info into your database.
They need to register the app in Azure AD and provide it access to Microsoft Graph for step 2 to work. If they're techie enough to find their tenant id, register the app through the Azure portal or with PowerShell, and copy ID's into the app's configuration file, that is not a problem. But I cannot streamline the configuration process for the less tech-savvy user.
Basically I want to do something in compiled C# that today is already possible with PowerShell: login as a directory administrator and register an application. So I don't see a security concern here.
We have a similar scenario running that does work, where we set up the app as a multitenant application in our Azure AD, and customers provide consent to access their Office 365 subscription on a web page. But that's not the idea. It's their data, there's no reason to run it through our tenant.
Maybe I'm missing the point completely and there is an easy way to implement this. But I've been sifting for weeks through AzureAD doc and samples now and I don't see it. Any help or info to support this scenario is appreciated.
Here as an answer:
You can register a multi-tenant app in your tenant.
That app can be granted access to create a new app in the customer's tenant. Then you have a new single-tenant in your customer's AAD.
That app should be granted access to the resources your solution needs access to. That is what we ended up with for our solution.
The customer can revoke access to the multi-tenant app that has write access to AAD as soon as the new app in their own tenant has been created.
All objects in Azure Active Directory live within a Tenant, including Application Objects. When referencing any object in the directory, you must first establish tenant context, and then you are allowed to query the data within that tenant. There is nothing we provide (that I know of) that exists above the top level Tenant structure.
When you say "It's their data, there's no reason to run it through our tenant." I feel like there is a slight misunderstanding of how data flows from the directory to your application.
All OAuth 2 client applications need to be registered somewhere. All different service providers offer some sort of client registration process. Azure Active Directory simply takes advantage of the existing Tenant structure to register applications. This also allows for a number of other features like admin controls, user assignment to apps, conditional access policies, etc...
Now when you register a multi-tenant application in your tenant, you are really just establishing a home for where your client's registration is stored. No data actually makes it's way into your tenant, or is stored in your tenant. We simply reference the Application Object in your tenant to understand what the current configuration of the application is.
We do ask the users who use your application to provide consent for your app to get that data. When users sign up to use AAD, Microsoft makes a promise to those users to keep their personal and private data safe. (I am sure we use much more legal terms than that, but you get the idea.) We cannot simply hand over things like user's phone numbers, email addresses, etc without first knowing that the user is OK to hand that data over to you. There is nothing you can do to bypass consent, and there really shouldn't be a way to do this.
However, these concepts are slowly changing with the future of our application model. In App Model V2, we allow AAD Users or people with Personal Accounts to register applications that allow both AAD and Personal Accounts to sign in. This means that you, without an AAD account, could create and register apps for the scenario you described above.
Learn more about that here:
Sign-in Microsoft Account & Azure AD users in a single app

Drive.API.v3 Different Accounts username / password authentication

So I have a few accounts that have documents on them, and having to switch between them all the time is quite frustrating, so I wanted to have them shared so that I can just have a link to view the file (no editing or anything).
Problem is, now with v3, I seemingly have to add the Drive API to every account that I want to view, which doesn't work for me. It's too much of a hassle to go through ALL of the accounts, when I have the username/password for them all already.
Is there a way to have a list of all my accounts username/passwords and somehow query to get a token to view only of the files? Or is this completely not possible anymore with v3.
I can get it working fine but instead of username/password, I have to enable drive API on the account, copy/paste the credential/secret instead of the username/password, and it works perfectly. I can search through all the files I have 'found' by accessing and reading the files and AlternateLink's accordingly... I just would like a non-intrusive way for my application to do this.
This is written in C#.
Unfortunately you can no longer use username/password via an API since the ClientLogin API was shutdown in 2015.
Using OAuth, each user can be prompted to grant permission to your application. They need do this only once.
Alternatively and if the user accounts are GSuite based Google accounts, then your C# program could use a single service account and impersonate any or all accounts on your domain (once given permission to do that by your domain administrator). This obviates the need for each user to grant permission to your application. You can read about how to do this in the Delegating domain-wide authority to the service account doco.
Another alternative may be to create a google group and make all 3 accounts members of that group. Then share a folder (view, comment or edit access) with that group and put all files and sub folders there into that folder.

How to build from VS Team Services to Azure web app once and for all?

Preword and why this is not a duplicate:
Aight, so after failing miserably at how to deploy?, troubleshoot azure resource manager service endpoints, Continuous Delivery for Cloud Services in Azure, Deploy ASP.NET apps to Azure cloud services, Deploying an Azure Web Site using the new build system in Visual Studio Online and every link in “Similar questions”, I want to ask this question:
How to set up continuous deployment (integration, builds, whatever) from Visual studio Team Services (VSTS/TFS) to an azure web app?
What is it I’m missing?
The issues:
I tried to create a build definition, and immediately ran into “insufficient priveleges. I am full admin on the TFS account, and owner on the Azure account. I thought maybe I could hack around with get-AzurePublishSettingsFile, some tokens and stuff, and this is what I get:
Right, I recognize the old portal, though I hadn’t seen it in a while, but I am owner on the azure subscription. What on earth is happening?
Fine, it wants a service administrator or co-administrator, I make one:
There are no such things, and I can’t create a role. No service admin, no co-admin, nothing. I’m owner and I can’t create roles? That’s super-weird.
The eventual problem, I learned is in active directory, if I can allow users to register applications…
Okay, maybe create user in AD, and see if this helps?
Nearly every description of continuous integration out there describes use of classic portal.
How can I get classic portal back? I used to use it a couple years ago, but lost traction ever since it started to automatically redirect to the new metro style portal.
How can I enable authorization for azure ←→ TFS online?
App Service Name refers to the name of the application as it is displayed in the list of “App services” in Azure portal?
App service URL refers to the native url given by Azure to the application, or is it one of the custom domains I assign to the app, or is it the “publishUrl” I can find in the application’s .publishsettings file?
Is SetParameters file important? Is it related to the config transformations or the publish profiles of the individual apps?
I’ll go get my AD administrator and try to get the company AD on this subscription, but I have little hope it can help.
Insufficient privileges to complete the operation
As I known, this could due to a permission issue that may caused by the following causes:
User has only guest permission in the directory
User is not authorized to add applications in the directory
For more details, you could refer to this tutorial to troubleshoot this issue.
You need be a member of the Global Service administrator or Co-administrator role in old portal as follows:
Note: You could contact the Service administrator or Co-administrator of your subscription and add your account as a Co-administrator.
Classic Portal can be accessed if you are subscription admin or co-admin. What your role is in the new Portal doesn't matter for this. You can only be added as co-admin in the Classic Portal by the subscription admin or another co-admin.
To authorize in ARM mode (as you are trying), TFS/VSTS needs to create a Service Principal in Azure AD. This requires that your user is an admin in the Azure Active Directory.
App Service Name is exactly that. But you don't need to worry about knowing what to input, the list will be populated automatically from your subscription.
App Service URL allows you to name a variable that will contain the URL. You don't have to put anything there.
SetParameters file is used by Web Deploy. It is also not mandatory. You can find more info on it here:

How to secure my multi tenant webapp that is running on Azure

I'm struggling with my MVC5 webapp that is hosted on Azure. I need to secure it (of course) but I don't want to let the users create yet another account, with another password they can forget.
So I've looked into Azure Access Control (ACS). It looks nice, but the Identity Providers provided are very limited. I'm missing LinkedIn as an IP for example. Therefore a lot of users will have to create a new account with a company emailaddress. Facebook user typically use their private emailaddress.
So Azure Active Directory looks fine. You can federate with a local Active Directory. But after diving into it, it seems that you cannot create a tenant from you code. So the user must first do thing in the Azure portal, and that is confusing and I want to make things as easy as possible.
What do I need:
authentications of users without storing their password myself
creation of new users by code
be able to federate to a customer's Active Directory (on premise or Azure Active Directory)
user must be able to use whatever emailaddress they're using
Do you have good suggestions to accomplish this?
You can manage users in AAD using the Graph API.
Using DirSync or AADSync, you can propagate your on-premise users to AAD.
User will have to logon on-premise and again in the cloud but using the same credentials. (Same Sign On).
Adding ADFS to the mix gives you SSO. (Single Sign On).
Typically, only the corporate domain can be used for email address.
For other applications, look at: Azure Active Directory applications.

Google Apps: Access to domain users' contacts as an admin

As a Google Apps administrator, I would like to add specific contacts to all my users' address books.
Which API should I be looking at? As I understand, the Contacts API requires the user to be logged in as the user who's address book I'm trying to modify. In my case, I can only be logged in as the administrator. I can also pass in the administrator's credentials (as is the case for all of the provisioning APIs).
I prefer to use the .Net libraries, if possible.
If you want to add them to be shared for all the domain you can use this application:
which imports contacts from CSV into the shared contacts (it takes 24 hours).
Or you can create your own application, personally I made 2 programs and used for on python and for the other php(although google doesn't offer for php a gdata library you can find one from Zend).
If you want to add them to specific users you need to write your own code there is no application I know of, and use a Oauth 2.0 login to login on their behalf (as long as you are administrator of that google domain) to use the API in their name. Personally I didn't dealt with this but received an answer that is possible ) . Connecting with their name and password is only one of the authentication types called: clientlogin , but there are also other ways you can connect on their behalf.