Our current solution is an ASP.NET WebApi server and various client apps which run:
Our on-premises: Server and web clients run in our premises. The customer databases are also found here. The main app (WinForms) is installed on the customer's users pc's.
Customer on-premises. Server, database and main app (WinForms) are available within the customer infrastructure. Web clients are still located in our premises.
The projects / apps:
Database: SQL Server database, non multi-tenant, ie. database per tenant.
Server: ASP.NET Core WebApi, non multi-tenant. Connects to different local customer databases. Users might be local AD users or users created in the authorization server (3).
Authorization Server: ASP.NET MVC app that uses OpenId to authenticate and authorize uses. Used by the server (2) and clients below.
Main client app: WinForms app that connects to a server (2).
Dashboard apps: Blazor server-side apps, multi-tenant. Connect to a server (2) using host name strategy.
Web apps: Mixture of ASP.NET MVC and ASP.NET Core apps, non multi-tenant
We would like to move to a SaaS architecture. We will choose database per tenant to avoid noisy neighbor problems and data contamination, as well as security.
The main development work will be development a web-app to replace the main WinForms app.In this case, I see to possibile solutions:
Expand the server (2) to add razor pages. Additionally, the server must become multi-tenant.
Create a web app. the current WinForms app is huge. However, user size is in the low to mid 1000.
In this situation what would be the most practicable solution for the main client app? Blazor Server-side or ASP.NET Core Razor pages?
Any other solutions that might be considered?
Related
I'm pretty new to Azure, and I wanted to get familiar with using Azure AD auth as an authentication provider for a dotnet core web app.
I followed this tutorial: https://learn.microsoft.com/en-us/azure/app-service/tutorial-auth-aad?pivots=platform-linux
It worked as described, but I have to be missing something, because the way it's deployed doesn't make any sense to me.
The "starting point" tutorial code is this repo, here: https://github.com/Azure-Samples/dotnet-core-api
It's a simple dotnet core web app that hosts an Angular frontend. Through the course of the tutorial, you make some changes to get the "frontend" to talk to the "backend", and you add two remotes to your Git repo - frontend and backend - but they're on the same repo.
As I understand it, at the end of this tutorial, I have two nearly-identical Azure App Service instances running in my Azure resource group. They are both running the same code. Both include the full-stack application - both are hosting a Kestrel or HTTP.sys (or whatever) instance on port 443 at their respective .azurewebsites.net URL - both show my index.html page - but one is supposed to be the "frontend" and the other is supposed to be the "backend". The only thing different about the "frontend" and "backend" is that the "backend" has an identity provider configured, and the "frontend" has API permissions granted to it from the "frontend".
Is it really necessary to have the whole service running in both places? Is there a way to host the actual dotnet core API service as an App Service, host the HTML / JS / CSS separately as an Azure Static Page (or something similar), and still configure the identity provider? Or does it have to be like this? It seems like overkill, from a technical standpoint, as well as from a billing standpoint.
As #Caius Jard mentioned, we can include both of them in a single solution. We can actually use MVC Web Application in this case where we can create a frontend in view and write the actual code in control. If we are using a core application then we can create the backend and frontend in two environments such as Angular for Frontend and .Net core for Backend and integrate them.
REFERENCES:
Azure AD Authentication For MVC Web Application (c-sharpcorner.com)
Angular and .Net core - Azure AD authentication | The-worst.dev
We built a .Net Core Web API application(Having Controller, Business Layer, Service Layer, and DB access layer in it) with a repository and unit of work pattern and we deployed it in the application server since the application server alone can access the Oracle DB server.
The mobile app will consume this API to get/save data from oracle DB. Now the issue is our IT team is not ready to open up the port and they told us that all the requests to the application server should come through a web server.
Case 1:
If we deploy our Web API application on a web server mobile app can access API but It won't able to connect to Oracle DB as it can be accessed only through the application server.
Case 2:
If we deploy our Web API application on an application server it can connect to Oracle DB but the mobile app cannot consume Web API.
The approach I am thinking of is to create another Web API application and deploy it on the webserver and so that the mobile app will consume the newly created Web API on the webserver and then it redirects the request to an actual Web API in the application server
Is the above approach is right or What are the approaches or best practices** that we can take to resolve this issue? Please share your valuable thoughts on this
We are starting to use IdentityServer as a centralize peice for User Authentication/Authroization + Securing our Apis and Applications.
We have few applications written using various frameworkks like WebForm Application, Desktop Application, .NetCore Mvc Web App, AngularJS Spa based Application and few apis built using MVC (.net Core).
We are starting with 2 Apis and AngularJS Application (using Implicit flow) and we will potentially migrate user from existing Database to IDServer Db.
I was told by our Enterprise Architect that we want to be able deploy IDServer in three tier. Presentation, Application and DB.
My Understanding is IDserver is nicely integrated with IdentityDbContext, ConfigurationDbContext and OperationDbContext.
I am not sure how can I break IdServer in three layers and extract application layer out of it for it to be able to deploy to Application Server expose via Http? Also IDServer expose lot of Http Endpoints as well like token/Connect, /.last-wellknow-configuration and /userinfo... so I am confused if it's good idea to even break that into 3 tier?
I have a requirement where i have an option of migrating all website which are asp.net webform & MVC based to a new dedicated server or Cloud server. I am not much aware of internal dynamic of clod hosting and most of the providers are not clear about the concerns i have.
Let me put it this way.
I use asp.net session variable in bot webforms & MVC how can i handle these session on cloud hosting Will session variable break in cloud enviroment in case single user session is severed by multiple instance on different servers in cloud
I am Using MS SQL Server 2008 R2 edition what should i consider for cloud
We have Apple Push certificate installed on dedicated server can we install same on cloud server
Can we have FULL TRUST level in cloud as we are using one application which need FULL TRUST level access to work.
Is there different version of Plesk for cloud server or we can install same Plesk etc.
If issue is with defaul session In-Proc then i can use SQL Server based session to get around it.
Do i need to take into consideration anything that can effect websites from working on cloud from configuration point of view or code point of view.
What steps should i take for migration from windows dedicated server to cloud server.
I have a WinRT app that is going to interact with a WebAPI service on my server backed by an Entity Framework managed SQL database (MVC - ASP.NET). For security, I'm only allowing users authenticated on the WinRT side with the Microsoft Live Connect SDK to interact with the WebAPI service. I already have the login code for authenticating with the Live Connect SDK on the WinRT app side working. The WebAPI service is running in the context of an MVC Web Role running on my Azure hosted server.
I've done a lot of reading on StackOverflow and there's a wide range of documents on the topics of authentication, OData, OAuth, Azure Mobile Services, WebAPI and how to combine them:
Live Connect Authentication Token for use on Azure Mobile Services (REST)
How to use a MVC WebAPI OData endpoint securely?
Disable Windows Authentication for WebAPI
I am very concerned that I choose the tools/path that implements only what I need to implement the above scenario and in a secure manner. My main attack concern is un-authenticated users trying to access the ApiController and performing harmful Puts or Deletes. Some questions:
Do I need Azure Mobile Services at all?
What tool(s) do I use or configuration changes do I need to make to manage/pass the Live Connect token between the WinRT app and the service?
Is there a template or NuGet package that I should use that automates much of this?
Is there a document that addresses my scenario or one close to it?
Is there anything built-in to Entity Framework that can help, or conversely has a vulnerability I need to address? If so, what?
What changes do I need to make to the server configuration (web.config)?