For my Azure Web Service, under Properties, the FTP/DEPLOYMENT USER seems to be of the form:
websitename\azuresubscriptiondirectoryname
But under Deployment Center, FTP, Dashboard, it is of the form:
websitename\$websitename
Where do I get the password for the first one, ie FTP/DEPLOYMENT USER?
The first one are user-level deployment credentials, they allow you to deploy any app in your account, as opposed to app-level credentials (the second you mentioned).
Assuming that you haven't configured them yet, you have to open the "Deployment center" section of your App Service. If you have multiple App Services, any of them will do).
Refer to this link for a how-to.
Related
I have a Asp.Net Core Razor Pages web app that has some pages Azure AD authenticated and some unauthenticated/anonymous. It works perfectly when I run in the debug mode in Visual Studio. When I publish the same on the Azure Web App I can either make the entire web app Authenticated or Unauthenticated. Is there a way to allow both at the same time?
From the azure portal, we can see that azure webapp does not support simultaneous settings. But we can set it from the code, and Noah Stahl and Tiny Wang are correct.
Phenomenon:
Create a simple application that does not include login, or simply put an index.html file, we can set it on the portal to perform the third-party login function.
As you can see, you can only choose one, Authenticated or Unauthenticated. And if you choose Authenticated, you can also choose one of the providers. This function is the simplest function in the portal.
Suggestion:
If you want to achieve multiple third-party logins, you still need to start from the code level so that you don't need to set up on the portal. It should be too simple on the portal.
You can refer below official doc:
Facebook, Google, and external provider authentication in ASP.NET Core
When you implement it, you can still access other resources in the unlogged state. When you need to log in, all supported third-party buttons will appear on the login page. Click the button to log in.
The option setting in the portal is a restriction on the current global access to the entire website.
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
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
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 am hosting web application in azure active directory.
I want to enable an option called as “External Access” after clicking on the applications button.
Now, the issue is when I click on “Add app” , I am not getting the option to select “Single sign on,read directory data”( I have added the screen shot below) , so eventually the “External Access” is not getting enabled in the applications tab.
Any solution for this?
Guess currently this option is renamed to Application is MultiTenant and you have to set this option for external access in the respective application's configure section.
"External access" means that it is a multi-tenant application, where you expect to have more than one organization (or at least more than one directory) consuming the application. As #Bamura mentions, this was renamed in the Azure portal to "application is multi-tenant".
"Single sign-on", "read-only", etc. are permissions that an application has to a resource. One of these resources is Azure AD itself (via the Graph API), but it isn't the only one. For example, you can have one application representing a web API, and another application representing native client apps that access the web API.
You can control which permissions an app has under the "Permissions to other applications" section at the bottom of the 'Configure' screen. You'll notice the default is single sign-on delegated permission (i.e. as a user).