Last post Jul 20, 2020 03:50 PM by bruce (sqlwork.com)
Jul 17, 2020 10:55 AM|Ligesh Koshy|LINK
I got a requirement to make a redesign of monolithic applications to clean architecture.
I have some legacy applications deployed in IIS, which is using a common web API project for all the applications. This makes the project tightly coupled. And the deployment on one application affects another. We are using ASP.NET Web API with Entity framework
which is been used by a frontend app (React/Angular)
Consider the applications like we have a root application called
https://www.example.com. And all remaining applications are subsites under this root application like
https://www.example.com/application1. We use WebSSO for authentication, token-based authentication. If a user signs in, to the above applications, the web API calls use this token to Authorise the user and
In the proposed system, we are thinking of separate Web API project for each application but the token authentication needs to be a common module which is commonly used across applications. Can this be implemented like a microservices architecture in IIS?
Or a common decoupled module for all application (this uses a database to store bearer token details, expiry).
Please suggest a design to be implemented in IIS ( clean architecture), where this can be migrated later to Azure environment with less development effort.
Jul 20, 2020 03:34 AM|YihuiSun|LINK
Hi Ligesh Koshy,
Jul 20, 2020 03:50 PM|bruce (sqlwork.com)|LINK
the login is simple, just a common url. as suggested an oauth service is a good choice.
what won't move to azure is the subsites. if you use subsides, your client code won't run into CORS issues because of the same origin (root site). but when you move to azure all the subsites will different origins and require CORS.
you can decide to have the root site proxy to the other sites. you could prep by giving each subset its own host header.