应该为更改域内部或外部的域设计权限吗？

Question

以下是域类：

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);
}  

这是用于域外授权的 Dao 类：

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

这是我在某些地方看到的 2 个方法，不知道哪个更好，哪个被认为是好的做法（这只是一个幼稚的例子，主要问题是放置此类授权的位置）：

// 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);
    }
}

那么如何设计这种权限检查（授权）呢？在允许 BookAR 更改其状态之前，如果特定作者是该书的所有者，如何设计验证（对于不需要查询权限的 CQRS，只需状态更改权限）？

Answer 1

简答：

您应该将业务逻辑与授权逻辑分开。 为什么？成功了：

• 更易于维护
• 更容易发展和更新
• 更容易运行关于用户可以在系统中执行的操作的审计报告。

长答案：

我已经围绕这个话题在 Stack Overflow 上提供了一些答案：

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

在这些答案中，我介绍了基于属性的访问控制 (ABAC) 和外部授权管理的概念。重点是：

• 您应该避免实现自定义代码来获得授权。
• 您应该清楚地将业务逻辑与授权逻辑分开。

现有的授权模型 (RBAC...) 过于以用户为中心，不会让您做自己想做的事。您需要在图书所有者和试图对图书采取行动的用户之间建立关系。

ABAC 中的步骤。 ABAC 使用（用户、对象、操作和上下文的）属性以与技术无关的方式定义授权策略，例如：

• 当且仅当 book.owner==user.id 时，用户才能编辑图书的元数据

NIST 最近在 ABAC 上发布了 report，我建议您查看。 XACML，可扩展访问控制标记语言，是 ABAC 的事实上的实现。 XACML 定义：

• 架构，
• 一种策略语言，以及
• 请求/响应方案。

您可以在OASIS website 和YouTube channel 上找到更多关于 XACML 的资源。