Handling security in C#Bot server-side

One of Codebots’ highest priorities is the security of the software which our codebots write, to the point where a diagram was made to focus on that sole purpose. This same level of care and attention was given to developing SpringBot’s security strategy.

When it comes to security, we categorise all work into the three A’s:

• Authentication,
• Authorisation, and
• Auditing

For authentication C#Bot utilises ASP.NET Identity to provide user identity services across the framework as well as OpenIddict for generating API tokens. For auditing the library Audit.NET is used for recording a log of user interactions with the application. All of which has been implemented on top of our security standard which ensures all third generation bots have the same level of security across the software stack.

This article will explore C#Bots’s security strategy, focusing on how to customise the three A’s within your application.

We recommend all readers also explore the security strategy for C#Bot, which has been documented in the security documentation section of your Reference Library.

Authentication

In regards to Authentication, all of the logic required for validating and generating user login tokens is found in serverside/src/Services/UserService.cs.

The general flow for a user logging in is as follows:

• User hits the login endpoint in serverside/src/Controllers/AuthorizationController.cs
• The controller calls the user service to validate the provided credentials
• The user service returns a token for a validated user with the user’s claims embedded inside of it
• The controller returns the token as a cookie or JWT token to the user that can be used to authenticate future requests

The general flow for an authenticated user requesting a protected endpoint is as follows:

• User hits the protected endpoint with a cookie or JWT token embedded inside of the request
• The token is deserialised into a claims principal by ASP.NET and C#Bot will use those claims to authenticate the user
• If required the user is passed down from the controller into the service layer for any further authorisation purposes

Authorisation

Any managed CRUD actions that occur in a C#Bot application occur in serverside/src/Services/CrudService.cs. This includes the regular create, read, update, and delete operations as well as other related features such as CSV export. The crud service acts as a managed layer over the underlying database service to apply security filtering on any operations that occur. It does this by calling serverside/src/Services/SecurityService.cs which reads the rules that have been created in the security diagram and either applying filtering operations or introspecting changes that are going to be applied, and then accepting or rejecting them.

All bot written endpoints use the crud service for accessing entities specified in the entity diagram. If there is a case where the security rules need to be bypassed the underlying database context can be reused to escape any restrictions.

The best way to modify any security related features is through the Security Diagram.

Auditing

By default, auditing is enabled and can be used to track the changes of the data within the application.All CRUD (create, read, update and delete) events are logged directly to the system logger with mutation events (create, update and delete) being logged using Audit.Net. Read audits are handled separately but are also redirected to the system logger.

Auditing Sensitive Data

Not all data should be audited, such as if it is of a sensitive nature. These fields can be specified in the code by marking the field as ignored by the auditing framework. An example of this can be found in serverside/src/Models/User.cs in which the password hash of a user is ignored by the framework to make sure it is not logged.

// Need to import the auditing framework
using Audit.EntityFramework;

// In the model class
[AuditIgnore]
public override string PasswordHash { get; set; }