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
provide output.
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.
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.
None
0 Points
1 Post
Design loosely coupled web applications in IIS sharing common resources
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 provide output.
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.
Thanks
Lijesh
Participant
920 Points
326 Posts
Re: Design loosely coupled web applications in IIS sharing common resources
Jul 20, 2020 03:34 AM|YihuiSun|LINK
Hi Ligesh Koshy,
Best Regards,
YihuiSun
All-Star
56394 Points
14756 Posts
Re: Design loosely coupled web applications in IIS sharing common resources
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.