Should one design permissions for changing the domain inside or outside of it?

Question

Here are the domain classes :

class AuthorAR {
    private $authorId;
}

class BookAR {
    private $bookId;
    // book owner
    private $authorId;
    private $title;

    public function changeTitle($title) {
        $this->title = $title;
    }
}

// This will be in the domain layer to make explicit the finding of the book
interface BookRepository {
    public function findByBookId($bookId);
    public function findForAuthorIdByBookId($authorId, $bookId);
}  

Here is the Dao class used for authorization outside of the domain :

class AuthorizationDao {
    public function findBookOfIdForAuthorId($bookId, $authorId) {}
}  

Here are the 2 aproaches that I've seen in some places and don't know which is better, which one is considered a good practice (this is just a naive example, the main question is where to put this type of authorization) :

// Aproach 1 : call the repository with the method made explicit in the domain,
// in order to check if the book with a specific author exists
class ChangeBookTitleCommandHander {
    public function handle($command) {
        $book = $bookRepository->findForAuthorIdByBookId($command->authorId, $command->bookId );

        if($book === NULL) {
            throw new CommandHandlingFailedException();
        }
    }
}

// Aproach 2 use an authorization service inside the controller to check if a user  
// has access to the specific book resource in order to change it's title
class Controller {
    public function changeTitleAction() {
        // This will use the authorizationDao->findBookOfIdForAuthorId($bookId, $authorId) to allow
        // access for changing that resource
        // @throws UnauthorizeAccessException
        $authorizationService->authorizeCommand($changeBookTitleCommand);
    }
}

So how to design this type of permission checking (authorization)? How to design the verification if a particular author is the owner of the book before allowing the BookAR to change it's state (in the case of CQRS where no querying permission is needed, just state change permission) ?

Answer 1

Short answer:

You should keep business logic separate from authorization logic. Why? It makes it:

• easier to maintain
• easier to evolve and update
• easier to run audit reports of what a user can do in the system.

Long answer:

I have already provided some answers on Stack Overflow around this topic:

• Permissions design pattern that allows date-based access
• Best Practices for securing a REST API / web service
• Fine-grained authorization for web applications

In these answers I introduce the concept of attribute-based access control (ABAC) and externalized authorization management. The point is that:

• You should avoid implementing custom code to achieve authorization.
• You should cleanly separate the business logic from the authorization logic.

Existing authorization models (RBAC...) are too user-centric and will not let you do what you are looking for. You need a relationship between the book's owner and the user trying to act on the book.

Steps in ABAC. ABAC uses attributes (of the user, the object, the action, and the context) to define authorization policies in a technology-agnostic way such as:

• A user can edit the metadata of a book if and only if the book.owner==user.id

NIST recently published a report on ABAC which I recommend you check out. XACML, the eXtensible Access Control Markup Language, is the de-facto implementation of ABAC. XACML defines:

• an architecture,
• a policy language, and
• a request/response scheme.

You can find more resources on XACML on the OASIS website as well as on this YouTube channel.