Xây dựng opa-authzen-interop: Quy trình xác minh tính tương thích của OPA với AuthZEN

Sau khi phát triển plugin biến OPA thành PDP tương thích với AuthZEN, tác giả đã tiến hành xây dựng một kho lưu trữ riêng biệt có tên opa-authzen-interop. Bài viết này sẽ đi sâu vào lý do tách biệt mã nguồn kiểm tra, cách xác minh tính tương thích và lộ trình phát triển tiếp theo của dự án.

Trong bài viết trước, tôi đã chia sẻ về việc xây dựng một plugin biến OPA (Open Policy Agent) thành một PDP (Policy Decision Point) tương thích với tiêu chuẩn AuthZEN. Tuy nhiên, khi nhìn vào trang kết quả khả năng tương thích (interop), tôi nhận thấy rằng đã có nhiều dự án khác đang xác minh trên cùng một kịch bản.

Đó chính là động lực chính để tôi bắt đầu repository này: Tôi muốn đưa triển khai của mình ra sân chơi chung và xác minh nó tại đó.

Và thế là, opa-authzen-interop ra đời.

Bài viết này sẽ bao gồm:

Lý do tôi tách biệt repo tập trung vào khả năng tương thích (interop) khỏi repo plugin.
Cách các dự án khác tham gia vào OpenID AuthZEN interop.
Trạng thái hiện tại của opa-authzen-interop và các bước tiếp theo.

Bài viết giả định bạn đã có kiến thức cơ bản về PDP/PEP và AuthZEN Authorization API.

Tại sao lại cần một Repo riêng biệt?

opa-authzen-plugin chỉ chịu trách nhiệm cho một việc duy nhất: triển khai AuthZEN API trong OPA.

Trong khi đó, interop lại chịu trách nhiệm cho một mục đích khác: khóa các chính sách (policy), dữ liệu và bài kiểm tra cụ thể theo từng kịch bản, từ đó xác minh tính tương thích.

Nếu cả hai nằm chung trong một repo, ranh giới giữa mã sản phẩm thực tế và các bài kiểm tra xác minh đặc tả kỹ thuật sẽ trở nên mờ nhạt.

Phân tách trách nhiệm

Tóm lại: plugin là mã sản phẩm, còn interop là hạ tầng xác minh.

Các dự án khác có thực hiện Interop không?

Câu trả lời là có, chắc chắn rồi.

Theo phần giới thiệu chính thức về AuthZEN Interop, đã có bảy sự kiện interop chính thức được tổ chức từ tháng 6 năm 2024 đến tháng 12 năm 2025.

Trên trang kết quả của Todo 1.1 (authorization-api-1_0-02), OPA xuất hiện cùng hàng loạt tên tuổi lớn khác như Cerbos, Topaz, OpenFGA, Aserto, Axiomatics, WSO2, v.v.

Một ví dụ thực tế về việc triển khai công khai có thể kể đến là:

aserto-dev/authzen-topaz-proxy

Như vậy, cách tiếp cận "repo xác minh tập trung vào interop" không phải là duy nhất đối với dự án của tôi; đây thực tế đã là một mô hình phổ biến trong hệ sinh thái. Tôi đã đồng thuận với cách tiếp cận này và tách biệt các tài sản xác minh cho opa-authzen-plugin.

Trạng thái hiện tại (tính đến ngày 5 tháng 4 năm 2026)

Dựa trên README của opa-authzen-interop:

authorization-api-1_0-01 (đánh giá đơn lẻ): 40/40 PASS.
POST /access/v1/evaluations (đánh giá hàng loạt - batch): chưa được triển khai, trả về 404.

Hiện vẫn còn một khoảng trống rõ ràng cần hoàn thiện.

Trong khi đó, trang kết quả interop chính thức của OPA cho Todo 1.1 đã hiển thị các lần chạy authorization-api-1_0-02. Điều này làm cho mục tiêu tiếp theo trở nên rõ ràng: ổn định hóa hỗ trợ 1_0-02 ngay trong repo của tôi.

Hành động tiếp theo

Ba bước kế tiếp đã được xác định rõ ràng:

Triển khai POST /access/v1/evaluations trong opa-authzen-plugin.
Biến các bài kiểm tra trong opa-authzen-interop thành màu xanh (tất cả PASS) cho authorization-api-1_0-02.
Thêm các bài kiểm tra interop vào CI (Continuous Integration) để các lỗi hồi quy (regression) được phát hiện ngay tại thời điểm Pull Request.

Về dài hạn, khi các kịch bản interop phát triển, các đường dẫn Search/IdP (/access/v1/search/*) cũng nên trở thành mục tiêu theo dõi.

Mô hình phân quyền trong kịch bản Todo

Kịch bản Todo được xây dựng dựa trên mô hình "5 người dùng × 5 hành động".

Hành động	admin (Rick)	editor (Morty, Summer)	viewer (Beth, Jerry)
`can_read_user`	allow	allow	allow
`can_read_todos`	allow	allow	allow
`can_create_todo`	allow	allow	deny
`can_update_todo`	allow (bất kỳ)	allow (riêng mình)	deny
`can_delete_todo`	allow (bất kỳ)	allow (riêng mình)	deny

Trong ngôn ngữ Rego của OPA, input.subject.id được ánh xạ qua data.users, các vai trò (roles) được đánh giá, và các hành động có phạm vi sở hữu sẽ kiểm tra ownerID.

# can_create_todo: allow for admin or editor roles
allow if {
  input.action.name == "can_create_todo"
  some role in user.roles
  role in {"admin", "editor"}
}

# can_update_todo: editor can update only their own todos
allow if {
  input.action.name == "can_update_todo"
  "editor" in user.roles
  input.resource.properties.ownerID == user.email
}

Cách chạy thử nghiệm

Cách nhanh nhất:

make test

Nếu bạn muốn chạy bộ kiểm thử chính thức trực tiếp:

make up

git clone https://github.com/openid/authzen.git
cd authzen/interop/authzen-todo-backend
yarn install && yarn build
yarn test http://localhost:8181 authorization-api-1_0-01 console

Quy trình make test sẽ trông như sau:

Quy trình kiểm thử