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?
Related
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?
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
Currently, there is a layered architecture project where MVC as the presentation layer, WCF as the service layer. So they both can be hosted separately in 2 physical servers. The client requires same deployment structure for the new project which I'm planning to do in .net core.
If a .net core application developed in onion architecture, can it be deployed like a traditional 3-tier web-app? That is to be deployed in 3 physical servers (Web Server, Service App, Database) such as core MVC / Angular, web api, DB.
Update:
I tried following with .net core project
.net core MVC as presentation layer
Web API as Service layer
Then a problem in handling sessions. Sessions are handled in Web Server (MVC project). How to implement similar authentication as .net core MVC do not have db access, authenticating through web api project (Which acts as service layer), How to implement this with tokens?
Any best practices or guidelines available?
Thanks in Advance
I am building simple LOB application (online restaurant reservation application) and i want to support multiple client side application types like web site, windows desktop application, android application etc. So i think that best way to design system is to separate ASP.NET 5 WebApi which will provide interaction with database, authorization and stuff like that and than build separate solution with projects for client applications which will consume that API. One of those client applications would be Silverlight application. Problem is, how i consume my API from Silverlight application. I can't find any information to link Silverlight with ASP.NET 5. All i got isMVC6. Is it better to createASP.NET MVC6application, implement my APIs there and hostSliverlight` in that project or to separate it like i described?
Silverlight is dead, but it can easily consume REST API so why cannot it work with ASP.NET Core 1.0?
There is no need to have special documentation.
My question is based on ASP.net 5 and authentication. In particular, I'm trying to achieve integrating oAuth (2.0) into my solution as my logon method (the users can either logon using oAuth if this is how they registered, or directly with my own app). Using the template for an ASP.net 5 web app, I've successfully achieved the above but this isn't quite what I need.
I'm have an ASP.net 5 MVC (app1) for my front end UI and an ASP.net 5 web api application (app2) for my REST services, serving data to the UI. Nothing new to this approach.
I want my MVC front end (app1) to have no Entity Framework references and no reference to things like Sign in manager (if possible). Just keeping it as simple as possible. I have a login screen and I want to present the option to logon via facebook or google oAuth accounts. Instead of using the nice code MS kindly provides out of the box when you start a new ASP.net 5 web app (hey, why make life easy!), I want to use my web api to do as much as the work as it can (I realise somethings need to happen in app1 to make this work).
My goal is to keep my UI as simple as possible and offloading complex functionality (business logic, database access and other things such as caching) off to the web api app.
I'm having difficulties extracting the parts of the web app demo around oAuth, and moving it into the web api, to utilise from app1. Has anyone managed to do this before? Is this a bad idea? Has anyone a sample of this approach in new ASP.net 5 MVC.
Thanks for advice in advance!
We (that is ASP.NET) recommend you look at Identity Server. v4 is now built on top of .NET core. The OAuth components you see in templates for facebook, twitter et al aren't suitable for using against a WebAPI, they're there for interactive, browser based logins, not for javascript.
You would have your interactive app handle registrations as normal, then use Identity Server to issue a bearer token, pointing it to your identity database, and validate that within your WebAPI.
We don't recommend rolling your own.
You can build a WebAPI app with membership manager using ASP.NET Identity. ASP.NET Membership is now called ASP.NET Identity.
From the link you will see how you can create a WebAPI app that will support all basic ASP.NET membership functionalities (log-in, register, etc).
Once you have WebAPI setup with your (custom) ASP.NET membership storage (DB is auto-generated once you run the app.), you are set up with a RESTful web layer with data access. You can also customize the storage provider. See here: Overview of Custom Storage Providers for ASP.NET Identity.
The ASP.NET website (www.asp.net) has all the necessary information sufficient to create all that you said from scratch. For integrations with Facebook or others, you can check out this link: External Authentication Services with ASP.NET Web API (C#)