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.

Related

Is it possible to get SharePoint app-only principal for one site only using REST API?

There are many tutorials how to add principal for specific app manually for admin, like this:
https://learn.microsoft.com/en-us/sharepoint/dev/solution-guidance/security-apponly-azureacs
And it is okay it works. But is there a way to grant this principal with an API call instead of manual setup? It will still be requested with admin bearer token so it should have all permissions to set it up, but I can't find any way to do it.
There is a way, where if I have another app registered in my tenant with FullControl permissions it can use an API to give principals for other apps like this: https://learn.microsoft.com/en-us/graph/api/site-post-permissions?view=graph-rest-1.0&tabs=http
But I can't have another app and don't want it, I just want to use admin credentials to add an app principal to write to one specific SharePoint page with some API call so I can later control files in the site with my app. Is there a way to do it?
In short, the answer is NO.
When we use an admin account to sign into appregnew.aspx page, in fact we are using an app / principal which is created by Microsoft to get the access token which can be used to create your SharePoint App-only principal.
This official scenario is consistent with what you said you need to create an app first, and then use it to configure another app.
Therefore, it is expected. I'm afraid we can't bypass the first app creation for configuring other apps.

Use Azure Active Directory B2C without migrating users

We have a client that currently use a ERP-system to store all their clients. This is a closed source ERP so they can not change the authentication flow. Right now they have an authentication API that various other APIs use but development is slow. They are now facing a challenge in that they need to bring more systems in and given the current structure this takes time since their APIs are tightly coupled with the rest of the systems. They absolutely wan't to avoid other departments from creating applications with their own authentication simply because they cannot keep their pace up.
They wan't to keep SSO for all their customer systems but have better control which users are allowed to do what.
I have been reading about Azure Active Directory B2C and it seems really great. We use Azure Active Directory (AAD) authentication for our internal applications and it works flawlessly most of the time.
Here comes the two part question:
Is it possible to use Azure AD B2C and still keep users in the ERP? For example if we can connect Azure AD B2C to send a request to a service that responds with user data if that user exists given that the credentials are correct.
Extension of question 1. The current ERP-systems gives the user an access token and refresh token. Is it still possible to use Azure Active Directory B2C in this case? Basically add our own Identity Provider that will refresh the access token when needed. Is this a feasible thing to do and are there any guides in creating this? Perhaps IdentityServer4 could be used or can it be simplified? http://openid.net/developers/certified/#OPLibs https://github.com/IdentityServer/IdentityServer4
Given these words on their website I think it should work:
Support all platforms and open standards
https://azure.microsoft.com/en-us/services/active-directory-b2c/
Yes, it is possible. As Miroslav mentions, you should use custom policies. This requires a ramp up on custom policies which can have a steep learning curve, but essentially you would take the starterpack (see getting started) and you would modify the userjourney to not write to the B2C directory (basically remove this step). Instead, you would do a call out to wherever the users are. This call out can either be an OIDC identity provider or a REST API, which are specified using technical profiles.

User management with Azure Active Directory?

I am new to Azure Active Directory and I am bit confused about the concept and its capabilities.
I am developing an API and a native client application that will consume this API. I registered both the API and the client app in AAD and
I managed the authorization of the client application using my Admin credentials (Azure Account). But I still don't get it.
I want the users of my client application to be able to register to the app service and then use it.
Should I handle that myself within the API (user/password in database) ?
Or
programmatically create users in AAD when users signup for my application ?
Which solution is better if I plan to offer more APIs ?
If using AAD is the case I will be grateful if you provide explanations, useful links or code examples if possible.
Your question is quite broad, and is comprised of several questions, so it is hard to answer concisely.
If your users are already in your Azure AD, you should use that as the user store. If however, they are outside of your organization, you could use Azure AD B2C, which contains functionality for selfservice account creation. Or take a look at https://stackoverflow.com/a/16068340 for a suggestion on how to use AAD for public users.
If the users are already present in your AAD, and you haven't set up user assignment on the application in AAD, they can already log on to the application.
You can use role based security to grant users different levels of access to the API methods if you are interested in that.

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.
Question:
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.
Question:
How can I enable authorization for azure ←→ TFS online?
Question:
App Service Name refers to the name of the application as it is displayed in the list of “App services” in Azure portal?
Question:
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?
Question:
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: https://www.asp.net/web-forms/overview/deployment/web-deployment-in-the-enterprise/configuring-parameters-for-web-package-deployment

How can I run a command line process that requires AD authentication from a .NET web service?

This is almost identical to this question asked by another user, and is the sequel to a question I asked previously.
Basically, my company recently bought Tidal Scheduler. We need to launch jobs ad hoc from other process, e.g.: BizTalk, .NET web apps, etc. Our plan was to wrap a .net web service around the C++ API. That is apparently going away version.next, so we are instead trying to wrap a .net web service around their command line interface.
The client requires Active Directory authentication. Using pretty much every method below for impersonation we have been unable to successfully call the CLI from our .net web service. From what I read in the question linked above, we are trying to impersonate a user with more rights than the ASPNET account, and this causes a security hole.
Is there a better way to do this? Is there a way to make it work with the road we have already traveled? Any help is appreciated, we have sunk way to much time into this.
Side note: we did make this happen using PsExec, but at this point it's such a huge hack-around (it's a big enough hack-around as it is) that we would very much prefer not to use this in our environment.
One possible method would be to run the web service in an App Pool that has the credentials of the user you need to impersonate. (This is assuming the authentication is the result of trying the operation and failing as the account running the current web service....if it requires authentication even when running as the user you're impersonating, you're out of luck.)
The impersonated user will need to be a member of the IIS_WPG group on the box the web service is running under. It may also need a few local permissions. Just make sure the user you are impersonating as very limited rights on the box itself.
Perhaps what you need is a windows service that has your credentials. Then your web service can call your WIndows Service to execute whatever it is you want to do. A Windows Service is a project template in Visual Studio and the docs on MSDN are very straightforward.

Categories