I made a simple Node.js application that is using Google Cloud's Speech to Text API.
I could successfully authenticate locally, but how do I authenticate in production while keeping the credentials privates?
P.S. My application is not using any other server than Google's servers.
The credentials necessary for making client calls are based on a strategy called Application Default Credentials. These can be found through an environment variable called GOOGLE_APPLICATION_CREDENTIALS if the variable is present. If the the variable is not set, then the default credentials can be used. The following article provides detailed guidance on this topic:
Setting Up Authentication for Server to Server Production Applications
If your client is running outside of Google on your own premises (and hence not in a Compute Engine or GKE cluster) then the thinking will likely be that the credentials are contained in a file that is itself content protected by local OS access permissions. For example, contained in a file which has read permission restricted to either the user that runs your application or group that the user is a member of.
You need to be more specific to get more accurate answers
====================
OK, it's all about how you control the permission of your service account and there is a note in that page: "If you are developing a production app, specify more granular permissions than Project > Owner. For more information, see granting roles to service accounts."
You should use a specific service account needed to use this service. I don't have the particular role name(something like AutoML Viewer or Editor), and you need to test a minimum workable role in your Dev ENV.
After which, you can deploy your service into PROD and make sure the key with a 0400 file. So more or less the account can use limited service as expected
Related
does anyone know how do i give permission from my project in GCP to a function created and deployed in firebase? Because what i'm doing is the following:
From a site (deployed also in firebase) y call to the backend (Firebase Function)
The function itself, tries to get resources from my GCP project (in specific what instances are currently running)
Then, i receive them and show on the front.
The step 2 is causing my problems, currently when i'm trying to run it, it gives me the error:
Error: could not handle the request and in the log from firebase function i got: GaxiosError: Required 'compute.instances.list' permission for 'projects/projectID' so i know for sure that's a problem of authorization.
All this project worked just well 2 months ago, but my free trial expired and we tried to move to another GCP account and try to finish this project (With this i know the code works just right, the problem is for sure GCP because also, when i use others API ENDPOINTS not related to GCP resources, they work just well).
Any recomendation would be amazing, and if i didn't gave enough info just tell me. Thanks u for your time
Add an IAM role containing the required permission to the Cloud Function service account.
For example the role roles/compute.viewer has the permission compute.instances.list.
Review this page to learn more about Compute Engine IAM roles:
Compute Engine IAM roles and permissions
Firebase Functions are Cloud Functions. Cloud Functions uses the App Engine default service account for access control. The format of the service account's name is: PROJECT_ID#appspot.gserviceaccount.com. Find that service account under IAM and add the role mentioned above.
Cloud Functions Access Control
Some background, I am deploying a local ASP Core 3.1 MVC Application within our companies internal network. Currently working on it in a local dev environment, but will eventually run on a linux system where the URL is routed through our DNS server and given a nicer looking url than the plain IP Address. Our organization uses Azure AD and all our employees have microsoft accounts. I am trying to only allow logins via Microsoft accounts. I have followed the Quickstart guide within the Azure Portal, but am now getting the following error : "AADSTS50194 ... not configured as a multi-tenant application. Usage of the /common endpoint is not supported for such applications created after '10/15/2018'. Use a tenant-specific endpoint or configure the application to be multi-tenant"
The guides did not mention anything about configuring endpoints as far as I could see. I currently have it set to single tenant as it seems like it will only allow accounts that follow this format, employeesname#mycompany.com. The mycompany.com is the domain we own.
This app will service multiple users concurrently, but we only want our own employees to have access, no guests or exceptions.
Questions:
Is there a reason why I should use multi-tenancy, or is single-tenancy ok? If single tenancy, how do I go about configuring the endpoint?
I am new to 3.1 and the example project from Microsoft is 2.1 (I see where they seem to be configuring endpoints here, but not sure how to update this to 3.1)
So after moving back and forth between attempts in the Startup.cs file
services.AddAuthentication().AddMicrosoftAccount(microsoftOptions => {
microsoftOptions.ClientId = Configuration["Authentication:Microsoft:ClientId"];
microsoftOptions.ClientSecret = Configuration["Authentication:Microsoft:ClientSecret"];
//microsoftOptions.CallbackPath = "/signin-microsoft";
});
I settled with the above. I changed to multi tenant because the more restrictive pages will be granted manually so if someone manages to login inside our network, with their personal MS account, it wont make much of a difference
just be sure to use this in your layout file (or any razor views):
#if (User.Identity.IsAuthenticated)
to see if a user has authenticated correctly
Currently all of our web apps have their Application Pool Identity set to ApplicationPoolIdentity. Now, When an app needs to access some resources on some some server, say, add/read some file, the app performs impersonation in code to a user that has permissions to do this stuff. But now, we are contemplating to create a specific user for each app, and set its app pool identity to its specific new user. But I have noticed in the Advanced Settings dialog that Microsoft recommends to use the application pool identity, as shown in the following image:
Why does Microsoft recommends to use this identity, and is using a specific user is not best practice or a wrong move?
thanks,
ashilon
ApplicationPoolIdentity uses a concept called Virtual Accounts
and is implemented to have App Pool isolation.This blog explains
in detail about that .
ApplicationPoolIdentity is the recommended approach to have proper isolation between each website/application pool in IIS7+ onwards.So you can have code or files running for one website or app which cannot be accessed by no one else.
But for your scenario where you need to access resource on another server,When you use ApplicationPoolIdentity it uses the Machine identity only always.So the best approach is to use managed service account
Managed Service Accounts are a great way to manage Services
that need network access. Let Windows take care of passwords and SPNs
for you
Please find more information here ,here
But this has problem as only one managed service account can be assigned to one Server.Even with Application Pool identity,it will be using the $machineaccount to access network resources.
If network resources you have to isolate for each website/application,then your only way to create the separate User Account for each Websites and manage that.
Hope this helps!
I have two applications:
MVC Site (User-facing Web App secured via OAuth -> Google)
Web API Site ("Private" Web Services)
These are hosted in an App Service Plan in Azure. These web services will only be consumed by my own applications - I don't need to worry about outside consumption. In fact, I specifically don't want outside consumption. My Web App is using OAuth to Google - that shouldn't matter here.
So to get to the heart of my question: My web services currently have no authentication/authorization model in the code but I don't want it just publicly available to anybody. On prem, we just lock this down via IIS using Windows Auth and set the service account for the consuming web app to run as a user that Windows Auth allows access to. I'd like to do the equivalent in Azure.
I understand Azure isn't exactly the same but I have to believe this is possible. I have even gotten my web services locked down the way I want using the settings in the Authentication/Authorization tab (I can try to navigate to it but I only get my Swagger UI once I login with a valid organizational account). So half of my battle is solved but I cannot figure out how to do the other half - the equivalent of setting the service account for my consuming MVC application to run as.
Can I do this via the portal without having to code specifically to this scenario? I'd really like a PaaS-level or IaaS-level solution for the security portion of consuming the above locked-down services. I'm also open to other avenues if I'm going down the wrong path in having a PaaS or IaaS security solution to this problem. I'm not against making code changes - we did have a one-liner in our RestSharp code to engage Windows Authentication, but the bulk of the work/configuration was outside of code and that's what I'm going for here.
If going the IaaS path you can host the application inside of an VM in the exact same way as you did before when running it directly on-top of IIS. The benefit is that you can get running the same way as before but you will still need to manage the VM; i.e install updates and take care of its security.
However, if you want to have a PaaS solution, then you need to modify the code of your front-end application to pass on the authentication token to the back-end API, assuming the back-end accepts the same authentication as the front-end. See https://azure.microsoft.com/en-us/documentation/articles/app-service-api-dotnet-get-started/ as an example on how to pass on authentication information from one app to another.
Alternatively you can use the app identity to make calls to your back-end API. This way the calls are not related to any user but are instead done in the context of the app. See https://github.com/Azure-Samples/active-directory-dotnet-daemon for more details on how to set it up, both configuration and needed code.
If you want to allow your users to sign-in using their Google accounts then you could handle authorization to your API using the app identity (second alternative above), assuming the API is independent of the requesting users identity.
Enabling authentication for a Azure Web App directly through the menus in the Azure Portal adds Azure AD authentication in-front of your application and require your to pass an access token generated by Azure AD to your API for it to work.
I'm trying to confirm my findings on permissions.
In order for the SharePoint object model to be accessed from a console application or for that matter a WinForm application, the user running the application must have db_admin permission to the content database for the web application in question.
In order to use Microsoft.SharePoint.Administration (like calling SPFarm.Local.Solutions.Add) inside an ASP.NET application the following must be true:
The call must be wrapped with RunWithElevatedPrivileges like the following:
SPSecurity.RunWithElevatedPrivileges(delegate() { code to run } );
The user accessing the ASP.NET page must be part of the Farm Adminstrators Group (the page is running under _layouts)
The user in the identity of the App Pool for the web application in question must also be in the Farm Adminstrators Group
Does this information look correct?
Yes but within the web service code you call the functional code using RunWithElevated Privileges this bypasses the identity you are running the web service as and instead uses the SPFarmAdmin user to execute the code.
Alternatively host the web service in an app pool which uses the same domain account as your central admin site, and allow anonymous access to the web service. This would be safe for internal use only and would mean that the web service always had elevated permissions.
Edit: Contrary to Michael's comment I have assumed that this app is not going to be run from within the SP farm.
I would not recommend this approach at all as it is an unupported method of using the SharePoint OM.
You are much better off writing a web service that sits on the SP farm and uses the OM, and then access the web service mehods to perform your required functionality.
You could also look at the out of the box sharepoint web services.
RunWithElevatedPrivileges will not work in your scenario I dont think as it requires a base indetity to fall back on which in the case of code executing on the SP farm is the SP App Pool identity which is usually a farm admin account.
I am happy to be corrected on all of this, but certainly in my environment it would not be wise to invest in a non-standard and unsupported approach to a problem.
Yes the web service will need proper access rights, but this is easier to control with a web service running locally.
However if as you say the apps are always running on the server then using RunWithElevatedPrivileges will solve any permissions issues as you are in effect running that code as an SPFarmAdmin (as long as the app pool identity is configured correctly).
Note: you could use this approach with either bespoke web services or client apps such as console applications or windows forms.
Apologies hobbyman, I never saw you reply.
If you use RunWithElevatedPermissions then it doesn't matter which user the web service runs as, because you are effectivley impersonating a farm admin account.
You could additionally do your own impersonation within the web service and impersonate any user you wish.
Essentially if the web service is running within a given application pool then the web service will run under the indentity which the app pool runs as. Does this clarify things?