How to implement authorization that needs to be done in the same transaction as aggregate method runs in (DDD)?

Question

Generally most of the authorization in the system is done in authorization layer which then calls commands/queries from application layer, which call methods on domain aggregates. However there are several cases when authorization has to be done in same transaction where aggregate method is executed and this authorization requires some info/fields from aggregate that is going to be modified (for example user can edit only his own posts - we know if post belongs to user only after reading it from storage/db).

API -> controller (authorization) -> command/query -> aggregate.method()

Here is how example command looks like:

import _ from 'lodash';
import * as di from '@/framework/di';
import * as app from '@/framework/application';
import { ConferenceRepositoryImplMemory, Conference } from './../../../infrastructure/repositories/conference-repository-impl-memory';

interface UpdateConferencePayload {
  conference_guid: string;
  name: string;
  short_name: string;
  website_url: string;
}

@di.perResolutionChain()
export class UpdateConferenceCommand extends app.Command<UpdateConferencePayload, void> {

  constructor(
    private readonly conferenceRepository: ConferenceRepositoryImplMemory,
  ) {
    super();
  }

  public async execute(payload: UpdateConferencePayload) {
    const conference = await this.conferenceRepository.getByGuid(payload.conference_guid);
    conference.changeName(_.pick(payload, ['name', 'short_name']));
    conference.changeWebsite(_.pick(payload, ['website_url']));
    this.conferenceRepository.update(conference);
    await this.conferenceRepository.saveChanges();
  }
}

I think it can be done in several ways:

1. make command/query to take extra argument in addition to payload for example "checkIfPostBelongToUser(postOwnerGuid)" and then call it (with proper aggregate field) just after reading aggregate from db but before invoking aggregate method. However I think this is bad for testing the command because you have to test authorization in addition to command "behaviour". Also it's possible that same command could be called by moderator for example who can edit others posts or by internal system which does not have to be authorized at all. It would be possible to make this extra authorization command param optional though...

2. another option is to instead of one command "editPost()" make two commands "editOwnPost(..., userGuid)", "editPost()". Former one would throw exception if post aggregate read from storage has incorrect ownerGuid. In this case authorization could be done in authorization layer (if user is moderator then editPost().execute() else editOwnPost().execute. However I am not sure it this is a way to go because it's defining something between authorization and business logic on command level... also commands don't match domain logic and it feels like it should be done on domain level instead but again putting authorization to domain level is not a good thing AFAIK.

3. the last option I can think of is to start transaction in which command runs before command is executed, read aggregate, check it's fields (owner for example) and then if it's ok execute command. Thanks to dependency injection it would not require duplicated reads from storage etc, and command would be completely separated from authorization. In such case command controller would look like this:

import _ from 'lodash';
import * as di from '@/framework/di';
import * as app from '@/framework/application';
import { ConferenceRepositoryImplMemory, Conference } from './../../../infrastructure/repositories/conference-repository-impl-memory';

interface UpdateConferencePayload {
  conference_guid: string;
  name: string;
  short_name: string;
  website_url: string;
}

@di.perResolutionChain()
export class UpdateConferenceCommandController {

  constructor(
    private readonly conferenceRepository: ConferenceRepositoryImplMemory,
    private readonly updateConferenceCommand: UpdateConferenceCommand,
  ) {
    super();
  }

  public async execute(payload: UpdateConferencePayload) {
    const conference = await this.conferenceRepository.getByGuid(payload.conference_guid);
    if (conference.something) {
      throw AuthorizationError();
    }
    await this.updateConferenceCommand.execute(payload);
  }
}

I like last option the most because it makes authorization and application layers separate, however it also requires authorization level code to actually init transaction and read aggregate before the command itself is executed.

Which option (if any) will be best, I mean according to some DDD/other desing principles?

Answer 1

Option 4:

The rules that users can edit their own posts and moderators can edit all posts are business logic and should be encapsulated within the domain model.

I would pass the User (I would think of a better name) to the change method, something like:

conference.changeName(newName, changeRequestedBy)

In that method you can validate the id of the creator against the id of the passed in user and also check if the passed in user has the moderator role.

Answer 2

I'll stick with the Post example because you haven't made clear exactly what your actual requirements mandate.

I don't see a useful distinction between your "authorization" layer and your "command/query" layer. They are best combined (at least logically) into an "application" layer where authorization and command/querying are each their own cohesive mechanisms. In fact, the distinction above seems to be precisely why you are here asking this question in the first place.

Take the below for example:

/** 
 * this command handler is in your application layer and 
 * can therefore be given the responsibility of authorization
 */
public async editPost(cmd: EditPost): void {
    
    let user = this.session.user; // or wherever the user comes from
    
    let post = await this.posts.findById(cmd.postId);

    // must be either user's post or a moderator
    if (post.userId !== user.id && user.role !== "moderator") {
        throw "Unauthorized";
    }

    // execute domain logic (albeit quite thin!)
    post.name = cmd.name;

    // flow of control is now back in our application layer
    this.posts.save(post);
}

We are simply carrying out the application-level logic (including both authorization and I/O) necessary to fulfill our use-case. The above follows a conventional onion (or hexagonal) architectural approach. The only oddity is that the authorization for the above editPost method requires more than just information about the logged in User.

Maybe other methods use a more conventional decorator approach:

@role("moderator") // checks user's role and throws if not moderator
public async deletePost(cmd: DeletePost): void {
    // this is a continuation for the above if it didn't throw
}

The important thing is neither of the above is doing anything different. Where the former specifically implemented its own authorization, the latter is just a wrapper doing basically the same thing.

Maybe this is closest to option 3? I can't really tell.