Introduction

In this article

Goals

There are two technical goals guiding ASPSecurityKit development:

  1. To provide you a consistent, testable, comprehensive yet very flexible security framework. As a developer conscious of security nuances, while working on decently sized business-critical systems, it must have occurred to you that the security subsystem provided by the web framework of your project is quite basic, inconsistent or outright immature for any serious security enforcement and that you’ve to engineer a framework of your own to implement the rules and checks needed to secure the application. This realization repeats in every such subsequent project, and every time it happens you have to bring your old custom security framework, albeit in pieces or modified to suit this particular new project needs, as the earlier project was different either in the technology or business domain. (Btw, This was how ASPSecurityKit was also born.)
  2. To provide you ready-to-use security workflows commonly needed in every other multi-user web application. Another observation you’d have made that there are workflows (APIs/UIs/actions) that you’ve to repeat in every project serving multiple users. These workflows – although can require some sort of customization per project – are largely generic and reusable. It’ll save tons of your time if you could just get them out of the box in a new project with the capability to do the customization needed.

To serve these two goals, ASPSecurityKit comes in two forms – libraries and source packages.

Libraries

These are prebuilt binaries installed as NuGet Packages supporting multiple platforms or web frameworks. ASPSecurityKit libraries provide a comprehensive Security Pipeline to enforce identity and access rules on web requests including authentication, multi-factor and first of its kind activity-based, data-aware authorization.

Every component used in the security pipeline is interface based, and these interfaces are wired-up via a dependency framework of your choice. You can thus easily replace any component. The extensibility doesn’t end just there – the implementations of these interfaces declare their methods and properties as virtual so you can easily change the behavior of any member without having to implement the whole component yourself. This DI based design additionally serves a crucial goal of testability in component design, which aids in seamless automated testing.

ASPSecurityKit components diagram

For example, even the error messages returned by ASPSecurityKit for various security failures is based on an interface and the implementation of which declares different messages properties as virtual.

The models and repositories used by security components are declared as interfaces, for example, IUser<TId>, IUserRepository<TId>, IAuthDetails, IIdentityRepository, IPermit<TId>, IPermitRepository<TId, TEntityId>. This gives you ultimate flexibility to declare the model the way you want, with validation and other attributes on properties for example, and implement repositories with the database and data access technologies of your choice.

Components of the security pipeline have first-class support for both synchronous and async executions, so you aren’t forced to choose a particular one just because the other isn’t supported.

The core ASPSecurityKit library is platform or framework-agnostic and it implements the core components such as UserService, AuthSessionProvider, SecurityPipeline, AuthenticationProvider, MultiFactorProvider, AuthorizationProvider, multiple authentication scheme handlers and so on. This gives you the ability to refer ASPSecurityKit in such things as background jobs, to run those in the context of certain security identity for example, without having to bring the huge dependency of the web components. In ISCP, we leveraged this capability to run account/tax/reporting jobs in the context of desired provider identity – which was defaulted to use the default custodian provider context but could be easily changed to use other contexts as and when needed.

Zero Trust security model

The Zero Trust security model assumes breach as the default phenomenon and therefore, it advocates verifying every request with all possible options available to ensure the legitimacy of the request. It also emphasizes following the principle of least privilege access to limit access to the system for only the functions requested even though the elevated privilege might be available for the caller.

Zero Trust and least privilege access are fundemental principles to ASPSecurityKit design. Few examples:

  1. As you apply ASPSecurityKit’s ProtectAttribute on the base controller (or the base service in ServiceStack) or as a global filter, it instantly begins guarding all operations of your web application with a multi-stage security pipeline that involves, among other things, XSS validation, authentication, multi-factor, authorization. All these checks are necessary unless you disable one or more for specific operations.
  2. Following the same principles, activity-based, data-aware authorization components enforce that to execute an operation, the caller must possess its corresponding permissionCode, and any existing data being referred for the operation must also have been permitted. You can selectively exclude operations and data from these checks, but the default is to guard everything.
  3. The user verification, user suspension and entity suspension checks are designed to block every incoming requests if the corresponding check fails, and give you tools and control to explicitly exclude certain operations (of your choice) from the check.
  4. The IP firewall by default denies access if whitelisted IP ranges are missing. Similarly, if permitted origins collection is empty, origin restriction will report failure for using the associated public key.
  5. The XSS guidance we give is also a nice example of Zero Trust wherein each subsystem takes a responsibility to sanitize input/output data without considering that the other subsystems would have already done the same. If you don’t do that, you risk failures of one subsystem leaking through others and causing potential leakage of user credentials upon successful XSS attack.

Supported platforms or web frameworks

Source Packages

A Source package is like a project template – given to you in source form – which you’re free to build your project upon. However, that’s where the similarity ends. ASPSecurityKit Source Packages are more like libraries with fully functional components – installed as source code – giving you crucial security features or workflows, commonly needed in all multi-user web applications. For example, login/register, two-factor auth, forgot password, account settings - username/password/2FA, email verification, user/permission management etc.

Additionally, these packages include source code of models, repositories, migrations, DI configurations, etc. that you need to wire up security components and workflows into a fully functioning web application base that you can use to build upon business features of your project.

Source packages are available for all the supported web frameworks, and you can even start using ASPSecurityKit in an existing project with the Essential source package. For more information, visit the source packages page.

Installing source packages

You install A source package using the ASPSecurityKit.Tools NuGet package, which comes as a development dependency of ASPSecurityKit package. ASPSecurityKit.Tools extends NuGet with a couple of commands of which the primary one is start-ask which starts a graphical user interface (GUI) to let you connect and install source packages from the ASPSecurityKit dashboard. To learn more, check out installing source package section on Using The ASPSecurityKit.Tools page.