We are considering deploying some of our intranet web applications to Azure. The web applications are built using ASP.NET MVC. Source code is available, it is fully under our control. All our company machines are Windows 7 or up, part of a windows domain, sitting behind proxy a server. Users are registered in AD. What authentication technology would you recommend for a secure and convenient login experience? We prefer to save the employees from creating, remembering, typing in yet another username/pwd. Single-Sign-On is wonderful for the users. Can we achieve something similar? Up to what extent do we have to compromise on the convenience?
Reasons to move to Azure: Azure does not have the bureaucratic deployment obstacles that our intranet has. Furthermore, deploying webapps to Azure is just soooo easy and wonderful.
Azure Active Directory extends on-premises AD into the cloud, enabling users to use their organizational account to not only sign in to their domain-joined devices and company resources, but also all of the web and SaaS applications
(office 365) needed for their job.
Federated Single Sign-On for applications that support SAML 2.0, WS-Federation, openID connect.
Password based for apps with a html sign on page and Existing SSO using ADFS.
Related
I developed an internal portal that is relevant to the engineering team. I restricted access to the portal by implementing Sign in With Google and as expected it is only accessible to our organization email-ids only. Now, I want to host the portal and we use Google Cloud Platform. I want to further restrict access to the portal within the organization.
What are the possible solutions to host the portal internally using Google Cloud Platform? If I host the portal and gave access to public, what could be the possible security implications?
If I understand well your concept, you are running a Web portal to authenticate your organization users to access your Frontend application, which retrieves information on a GCS bucket to be displayed on this Web page.
In this situation, the Identity-Aware Proxy (docs) that could fit your needs.
The IAP lets you manage access to applications running in the App Engine standard environment, App Engine flexible environment, Compute Engine, and GKE. IAP establishes a central authorization layer for applications accessed by HTTPS, so you can adopt an application-level access control model instead of using network-level firewalls or VPNs. When you turn on IAP, you must also use signed headers or the App Engine standard environment Users API to secure your app.
In this link you can see a quick example of how you can control access to your web apps and VMs in GCP using the IAP feature.
we want to use azure web apps not only for production but also for pre-production sites. These sites should be accessible only for Users in our Azure AD or even better only users with specific roles in the Azure AD. Or as a workaround some form of authentification without changing the code of the App. Since the App should be available public in some point of time.
At the moment these web servers are hosted in our internal network so they are only accessible through vpn or on site.
How can I secure a pre-production web app?
I tried the built in authentifcation with AD but I can't authorize a specific AD Role or AD Directory without changing the application it self.
What would be perfect for us would be a simple Basic Auth on the web app which I understand is also not possible without changing the App.
Anyone facing the same problem?
Maybe there is a design pattern for this? Or some Gateway to handle this?
Any hints would help,
Thanks
Stefan
Follow this article which shows how to configure Azure App Service to use Azure Active Directory (Azure AD) as an authentication provider.
Some best practices when setting up your app and authentication:
Give each App Service app its own permissions and consent.
Configure each App Service app with its own registration.
Avoid permission sharing between environments by using separate app
registrations for separate deployment slots. When testing new
code, this practice can help prevent issues from affecting the
production app.
https://learn.microsoft.com/en-us/azure/app-service/configure-authentication-provider-aad
I have a MS Azure ASP.NET Core 2.x WebApp that uses standard Identity based authentication.
I would like to restrict access to the website to only a certain set of people.
I need the entire website to be hidden unless you pass some kind of authorization gate. The requirement, however, is that the gate should not interfere with the standard ASP.NET Core Identity authentication/authorization mechanisms.
Essentially, we have a website that needs testing by a distributed team, but we don't want the site to be visible to non-members.
TIA!
Your best bet is going to be using the network-level control that comes with an ILB App Service Environment. If that's too pricey, try the IP restrictions feature on the public app service.
I have implemented a website that uses Azure AD B2C as its authentication mechanism.
Everything works great except I recently ran into a firewall issue with one of my clients. When the client redirects to either *.onmicrosoft.com and/or login.microsoftonline.com my client's corporate firewall blocks the routes. And to further complicate my situation my client's corporate firewall restrictions can not be changed.
Is there any work around that anyone can suggest such using a headless login workflow that is orchestrated within the web server that hosts my website or possibly using custom domains that my client trusts such as login.mycompany.com?
Both of the approaches have outlined would be the ideal ways to deal with this restriction, unfortunately neither are currently available in Azure AD B2C.
Both of them are listed in the Azure AD B2C feedback forum for you to support and keep track of their progress:
Customer-owned domains
Add support for Resource Owner Password Credentials flow in Azure AD B2C and headless authentication in Microsoft Authentication Library
I can't think of any other approach, which is a good thing otherwise, it would mean someone could easily spoof Azure AD B2C.
Ultimately, the right thing to do is to work with your client to ensure these and all the endpoints your applications needs, are allowed through the firewall.
Saca is correct, the customer owned domains feature could be used to change the domain name when it becomes available. Work has started, but it's still going to be some time before it's publicly available.
Regarding your client's firewall restriction that blocks login.microsoftonline.com. If it helps, there are some things that your client should be aware of. Blocking this domain doesn't just prevent application / Azure AD B2C scenarios, it blocks all Azure Active Directory sign-ins used for Microsoft Office 365 and Microsoft Azure. This means that if some other organization were to share Microsoft resources with one of the employees of your client's organization, they would be unable to access them.
What could be the ways to integrate a web application ( on-prem) to another web application (Azure) using azure AD authentication( happening in the background), with out the user being prompted for credentials.
It depends on how your on-premise application authenticated. Based on the description, you want to implement the single sign-on for the on-premise application with the application which protected by Azure AD.
In this scenario, you can deploy ADFS on-premise and make the on-premise web application authenticate by the ADFS. Then we need to enable the trust from the ADFS to Azure AD. After build the federated trust, when the users try to access the web application which protect by Azure AD will redirect to the ADFS, and if the users already authenticate the on-premise application they will not required to enter their credential again. Here is a figure to demonstrate this progress and you can refer more detail about it from this link.
And now, we can use Azure AD connect to integrate your on-premises directories with Azure Active Directory easily. You can refer the video on this link about different settings for this tool.