StoneAssemblies.MassAuth Hands-on Lab

A few days ago, I introduced you StoneAssemblies.MassAuth as a  Gatekeeper implementation.

Today, as promised, I bring you a hands-on lab that consists of the following steps:

1. Set up the workspace
2. Contract first
3. Implementing rules
4. Implementing services
5. Hosting rules
6. Build, run and test

So, let’s do this straightforward. 

Prerequisites

• Visual Studio 2019 (16.9.3)
• Docker (2.3.0.4)
• Cake (1.1.0)
• Tye (0.9.0-alpha.21380.1)

Step 1: Set up the workspace

To set up the workspace, open a PowerShell console and run the following commands:

After executing these commands, StoneAssemblies.MassAuth.QuickStart.sln Visual Studio solution file is created, which includes the following projects:

• StoneAssemblies.MassAuth.QuickStart.Messages:  Class library for messages specification. 
• StoneAssemblies.MassAuth.QuickStart.Rules: Class library to implement rules for messages.
• StoneAssemblies.MassAuth.QuickStart.Services: Web API to host the services that require to be authorized by rules.
• StoneAssemblies.MassAuth.QuickStart.AuthServer: Authorization server to host the rules for messages. 

The commands also add the required NuGet packages and project references.

If you review the content of the StoneAssemblies.MassAuth.QuickStart.AuthServer.csproj project file, you should notice a package reference to StoneAssemblies.Extensibility. This is required because all rules will be provisioned as plugins for the authorization server. 

The extensibility system is NuGet based, so we need to set up the build to provision the rules and messages as NuGet packages. For that is the purpose, this workspace configuration includes two more files. The build.cake, a cake based build script to ensure the required package output,  

and the tye.yaml that will help us to run and debug the solution.

 

Step 2: Contract first

Let's add a bit of complexity to the generated problem, related to the weather forecast. For instance, let's say we will allow requesting forecasts from a certain date, as some forecasts may not be available due to the complexity of the calculations.

For that purpose, we will add the following class to the message project, to request the weather forecast with the start date as an argument.

Step 3: Implementing rules

Now we are ready to implement some rules for such a message. Continuing with our scenario, let's say the forecast data is only available from today and up to 10 days. This operation could be more complex through a query to an external database, but for simplicity, it will be implemented as follows.

Step 4: Implementing services

It's time to complete the WeatherForecastController implementation in the service project. It should look like this. 

Notice the usage of AuthorizeByRule attribute on the Get method, to indicate that the input message WeatherForecastRequestMessage must be processed and validated by the authorization engine before the method execution.

We also have to update the Startup class implementation.

  

Basically, the AddMassAuth service collection extension method is called to register the library services and also ensure communication through the message broker. Remember, StoneAssemblies.MassAuth is built on top of MassTransit.  Finally, to read the configuration via environment variables we must update the Program class to this. 

Step 5: Hosting rules

To host rules, we provide a production-ready of StoneAssemblies.MassAuth.Server as docker image available in DockerHub. But for debugging or even for customization purpose could be useful build your own rule host server. So, in the server project, we also have to update the Startup class implementation, to initialize the extensibility system and load rules. 

Again, to read the configuration via environment variables the Program file must be updated like this. 

Step 6: Build, run and test

Let's see if this works. So, cross your fingers first ;)

To build and run the project, open a PowerShell terminal in the working directory and run the following commands.

Open your browser and navigate to http://localhost:8000 to display the Tye user interface. 

You can see the logs of the rules host server to notice how extensibility works.

Let's do some weather forecast requests. For instance with a valid request

the output looks like this

but with an out of range request

the output shows an unauthorized response.

So, as expected, it works ;)

Closing

In case it doesn't work for you, you can always try to review the final and complete source code of this hands-on lab is in the StoneAssemblies.MassAuth.QuickStart repository is available on GitHub. 

Remember StoneAssemblies.MassAuth is a work in progress, we are continuously releasing new versions, so your feedback is welcome. Also, remember that it is an open-source project, so you can contribute too.

Enjoy «authorizing» with pleasure and endless possibilities.

Introducing StoneAssemblies MassAuth

What is Stone Assemblies in the first place?

It has been a long way before making this decision. I worked for state-owned companies for years, in fact, I still do, but now I try to see this from a different perspective. I did not keep any of the things that I built or designed in the years of work. Maybe just professional experience.

Now, I decided to start over again, by creating something more personal. Stone Assemblies is a new software development and consulting group or organization or project. Actually, if you are running a software business or starting a new one, you probably need us ;).

I cannot say that Stone Assemblies is a company or a small and medium businesses (a.k.a. PYMES). There are many regulations here in Cuba and probably I will need some legal assistance to reach that point. So, let's keep this simple. I just founded Stone Assemblies and of course, I'm the lead software engineer. That sounds great, doesn't it? 

The story of the name is quite funny, so I will probably tell you one day about it, but not today.

Some background and context

Last year I was outlining strategies to modernize the systems of an organization, implementing proofs of concepts, which would allow their legacy system to support more workload. 

This particular system is in fact a database-centric large monolithic one. There are several options to scale this kind of system. 

One of these options is vertical scaling, but they could eventually reach the same state. In fact, the database provider may have limitations to use all the resources, even those limitations could be expressed in the use license. But the main reason is that computational resources are finite.

The other option is horizontal scaling, but even when the database vendor has options for horizontal scaling, it doesn’t solve the fact that the system is actually a monolithic system with all the well-known issues of this kind of architecture. Again, this option could also have limitations expressed in the license.

Our research led us to review some well-known patterns, and we started with: 

Command and Query Responsibility Segregation (CQRS): CQRS stands for Command and Query Responsibility Segregation, a pattern that separates read and update operations for a data store. Implementing CQRS in your application can maximize its performance, scalability, and security. The flexibility created by migrating to CQRS allows a system to better evolve over time and prevents update commands from causing merge conflicts at the domain level.

In combination with a migration approach from the:

Strangler Fig: Incrementally migrate a legacy system by gradually replacing specific pieces of functionality with new applications and services. As features from the legacy system are replaced, the new system eventually replaces all of the old system's features, strangling the old system and allowing you to decommission it. 

and looking to maximize the added value for a minimum viable product (MVP), we identified one key feature of the legacy system, so, we decided to also include this one:

Gatekeeper: Protect applications and services by using a dedicated host instance that acts as a broker between clients and the application or service, validates and sanitizes requests, and passes requests and data between them. This can provide an additional layer of security, and limit the attack surface of the system.

What is Stone Assemblies MassAuth?

The key feature I mentioned earlier, is an extensive, exhaustive validation subsystem that is executed before any attempt of command execution. But all these validations - query base operations - are executed in the main single database demanding computing resources, to the detriment of the performance of the other commands that could be executing at the same time. Remember, this is a very high concurrency system.

The diagram below shows the monolithic shape of the system. 

Monolithic shape 

So, why not move all those validations to an isolated subsystem? The idea is to replicate all the slowly changing data, which is used in validation queries. With this only action, all validation workloads are executed in isolation, with the advantage that is also possible to assign dedicated resources to run these tasks. The following diagram depicts this scenario.

Validation workloads run in isolation (CQRS)

With this idea in mind, is not hard to generalize a solution that intercepts any message, and executes a preflight without impact the core system. This is the idea behind StoneAssemblies.MassAuth.

StoneAssemblies.MassAuth is a free, open-source distributed, extensible message-based authorization framework built on top of MassTransit. Actually, it allows you to improve the responsiveness and throughput, from a loosely coupled and message-driven approach. 

The following diagram shows, the result of starting to strangulate the monolithic system, segregate the responsibility of command and queries and the usage of StoneAssemblies.MassAuth.

Result of system modernization and evolution

By the way, if you didn't notice yet, StoneAssemblies.MassAuth is a Gatekeeper implementation. 

StoneAssemblies.MassAuth is also built on top of powerful and insane extensibility system StoneAssemblies.Extensibility.  So, basically, all authorization rules can be provisioned as plugins for the authorization engine, but that's part of another story. I will tell you more about this in the future.

Send us your feedback

This is a work in progress and we are continuously releasing new versions. Sources and sample codes, are available in GitHub including some Benchmarks. Packages as usual, are available in NuGet gallery and we also provide production-ready of StoneAssemblies.MassAuth.Server (a.k.a. authorization engine) as docker image available in DockerHub. 

Without too much to say, I just invite you to use StoneAssemblies.MassAuth and let me know what you think. You can also look forward to the next post where I will explain how to use StoneAssemblies.MassAuth from a quick start.

Remember, this is an open-source project, so, you are welcome to contribute. There are a lot of work to do, so you can contribute by creating tickets, with pull requests, or just by inviting me to a coffee ;)

Enjoy «authorizing» with pleasure.