/backend-access-management

Primary LanguageC#

backend-access-management

This is a test project that is being developed for demonstrating the use of .NET/C# stack, software Engineering best practices and architectural principles.

Solution

The solution has been designed as two isolated microservices for individual scalability and seperation of concerns. In actual deployment scenarios, an identity server for user management and ideally an API gateway needs to be deployed. Cloud native solutions offered by providers can be used for these purposes such as Azure API Gateway, AWS Cognite etc.

All requests are protected by JWT Token authentication.

  • JWT tokens have been selected for their simplicity and ability to carry claim information about the bearer. In production scenario, a more complex token validation mechanism can be employed for more granular access control and server side validation.

Access Service

This service provides REST API on Doors, Sites (Logical grouping of doors) and Permissions for CRUD operations.

  • Persistance layer of this service includes a SQL Database. Using SQL Server makes managing the data for this service clean and compact due to the relational structure of the data.
  • A Redis service have been used for caching in this service for reasons of centralized-distributed caching and scalability

Audit Service

Provides REST API for logging events generated by other services and event monitoring service for authenticated administrators. Data collected in this service is stored in a MongoDB server since it is in plain document format and involves no relations. MongoDB has been selected for its ease of use in aggregating large volumes of data and integration with monitoring tools.

For further improvement, we can deploy a message broker into the environment for async queueing of event logging.

Solution Architecture C4 Diagram

Container Diagram

How to Run

For running the project locally, we need to launch 3 services

  • MSSQL Server: The connection string needs to be adjusted in the src/Services.Access.Api/appsettings.json and the DBContext available in src/Services.Access.Infra.Data/Database needs to be migrated into the server

-MongoDB and Redis: These services can be launched by running below commands in the root folder of the solution

$ docker-compose up

Once the dependent services are up and running, we need to launch individual services using below commands

For launching Access Service, run below commands in a terminal. Once executed, the service will be listening in localhost:5000

$ cd src/Services.Access.Api
$ dotnet build Services.Access.Api.csproj
$ dotnet run Services.Access.Api.csproj --urls=http://localhost:5000

For launching Audit Service, run below commands in a terminal. Once executed, the service will be listening in localhost:5001

$ cd src/Services.Audiy.Api
$ dotnet build Services.Audit.Api.csproj
$ dotnet run Services.Audit.Api.csproj --urls=http://localhost:5001

Once the services are up and running, you can perform test requests by using the Postman environment and collection files available under the folder /postman

⚠️ In order for audit events to be logged successfully, the Access service needs to be aware of the connection endpointfor the Audit. In case the service URL needs to be different than localhost:5001, this settings need to be altered in appsettings.json file or needs to be added into an environment variable of Services.Access.Api project.

TODO

For further improving this solution we can,

  • Dockerize the services
  • Add swagger for API documentation, XML comments are ready for that!
  • Increase unit test coverage
  • Implement soft deletion to entities in the relational database