Microservice có nên là người dùng?

Chúng tôi đang cố gắng xác định cách tốt nhất để ủy quyền cho người dùng trong kiến ​​trúc microservice, trong khi đảm bảo microservice có quyền hạn chế. Kiến trúc của chúng tôi sử dụng dịch vụ ủy quyền trung tâm để xử lý việc phát hành mã thông báo JWT.

Chúng tôi có các yêu cầu sau:

1. Người dùng nên được giới hạn để thực hiện các vai trò nhất định. ví dụ: người dùng chỉ có thể tạo / sửa đổi / đọc nội dung mà mình sở hữu.

2. Microservice nên được giới hạn chỉ các quyền họ yêu cầu. ví dụ: một dịch vụ siêu nhỏ chỉ cần đọc dữ liệu từ dịch vụ khác nên bị cấm rõ ràng không được ghi dữ liệu vào dịch vụ đó.

Ví dụ: giả sử chúng tôi có một hệ thống nơi người dùng có thể tải ảnh lên dịch vụ lưu trữ hình ảnh. Chúng tôi có một dịch vụ gắn thẻ tự động gắn thẻ hình ảnh với một vị trí. Người dùng chỉ có thể CRUD hình ảnh của riêng họ. Dịch vụ gắn thẻ có thể đọc bất kỳ hình ảnh nào từ dịch vụ lưu trữ hình ảnh, tuy nhiên không thể sửa đổi / xóa.

Cách tốt để đạt được những điều trên bằng cách sử dụng mã thông báo JWT là gì? Một số giải pháp mà chúng tôi đã thảo luận là:

1. Dịch vụ lưu trữ hình ảnh hiển thị 2 API, một API có sẵn bên ngoài (cung cấp quyền truy cập CRUD của người dùng) và một API có sẵn bên trong (cung cấp quyền truy cập chỉ đọc nội bộ). Có vẻ không linh hoạt - điều gì xảy ra nếu một dịch vụ nội bộ khác cần quyền truy cập đọc / ghi vào tất cả các hình ảnh (ví dụ: một dịch vụ tự động xóa hình ảnh rõ ràng)?

2. Chúng tôi thiết lập hai quyền trong JWT của người dùng, một là CRUD_OwnImages, còn lại là READ_ForAnalysis. Dịch vụ gắn thẻ có thể xem người dùng có quyền READ_ForAnalysis hay không và nếu có, hãy đưa ra yêu cầu phù hợp. Chúng tôi có một dịch vụ siêu nhỏ khác kiểm tra xem người dùng có CRUD_OwnImages cho các hoạt động CRUD trên hình ảnh của chính người dùng hay không. Điều này đặt trách nhiệm lên từng microservice để đảm bảo rằng người dùng bị hạn chế đối với các hành động mà anh ta yêu cầu. Kho lưu trữ hình ảnh không có cách nào để hạn chế từng dịch vụ siêu nhỏ với phương pháp này, vì vậy nó có khả năng dễ bị lỗi và dễ bị lỗi.

3. Chúng tôi cung cấp cho microservice gắn thẻ người dùng của chính nó, với quyền READ_ForAnalysis. Sau đó, khi dịch vụ gắn thẻ yêu cầu hình ảnh từ kho lưu trữ hình ảnh, nó sẽ được cấp quyền truy cập vào những hình ảnh đó, nhưng bị cấm sửa đổi chúng. Người dùng của người dùng chỉ có quyền CRUD_OwnImages, vì vậy anh ta có thể truy xuất và chỉ có quyền truy cập vào hình ảnh của mình từ ngoại vi. Nếu một dịch vụ khác cần CRUD cho tất cả dữ liệu, chúng tôi có thể cung cấp cho CRUD_AllData hoặc tương tự. Chúng tôi thích cách tiếp cận này vì mỗi dịch vụ hiện chịu trách nhiệm về dữ liệu của riêng mình (thay vì logic đó được sao chép trên nhiều dịch vụ), nhưng nếu dịch vụ yêu cầu cả quyền người dùng và quyền microservice thì sao? Chúng tôi có thể gửi hai mã thông báo JWT (cả người dùng và microservice) một cách an toàn không? Có cách nào để kết hợp các quyền một cách an toàn và gửi thông qua đó không? ví dụ

Vấn đề sẽ trở nên trầm trọng hơn nếu cần thêm thông tin người dùng ở phía dưới (cách xa 2 hoặc 3 microservice). Chúng ta chỉ cho rằng tùy thuộc vào các dịch vụ micros micros riêng lẻ để hạn chế các hành động mà họ cần, và không làm cho điều đó rõ ràng?

Nói chung, càng nhiều hoạt động càng tốt nên được gắn với một người dùng thực sự, con người. Nó buộc mọi người phải xác thực đúng cách, nó thúc đẩy một chiến lược ủy quyền nhất quán duy nhất và đó là một phần quan trọng trong việc cung cấp một lộ trình kiểm toán gắn kết.

Và nói chung, bạn có ba loại kịch bản với microservice:

1. Người dùng đến, tải lên một bức ảnh và nó cần được gắn thẻ. Tuyệt quá. Dịch vụ ảnh chỉ có thể chuyển dọc JWT sang dịch vụ gắn thẻ (hoặc ngược lại tùy theo hướng phụ thuộc của bạn) và nếu người dùng thiếu quyền thực hiện thao tác phụ, bạn có thể thực hiện hành động thích hợp (có thể tải lên ảnh mà không cần thẻ , có thể trả lại lỗi, có thể một cái gì đó khác).

2. Người dùng đến, tải lên một bức ảnh và nó cần được gắn thẻ ... nhưng không phải bây giờ. Mát mẻ. Bạn xử lý ảnh bây giờ như bình thường. Sau này, khi việc gắn thẻ xảy ra (xử lý sự kiện / thông báo, xử lý lệnh kiểu CQRS, xử lý công việc định kỳ, bất cứ điều gì), dịch vụ gắn thẻ sẽ mạo danh người dùng (rất có thể bằng cách sử dụng một bí mật được chia sẻ để yêu cầu JWT tùy chỉnh từ auth) hoạt động phụ thay mặt cho người yêu cầu ban đầu (với tất cả các quyền và giới hạn của họ). Phương pháp này có vấn đề thường gặp với các hoạt động không đồng bộ khi khó cung cấp lỗi cho người dùng nếu mọi việc không suôn sẻ, nhưng nếu bạn đang sử dụng mẫu này cho các hoạt động dịch vụ chéo, bạn đã giải quyết được điều đó.

3. Một số hệ thống phụ cần thực hiện các công cụ bên ngoài bối cảnh của người dùng. Có lẽ bạn đã có một số công việc hàng đêm để lưu trữ hình ảnh cũ. Có thể các thẻ của bạn cần được hợp nhất ... Trong trường hợp này, bạn có thể muốn mỗi diễn viên này có người dùng giả riêng của họ với các quyền hạn chế và một ID duy nhất cho đường dẫn kiểm toán.

Việc sử dụng sẽ thay đổi tùy thuộc vào kịch bản, nhu cầu của bạn và khả năng chấp nhận rủi ro của bạn. Và tất nhiên, đây chỉ là một tập hợp không đầy đủ của khái quát đột quỵ rộng.

Nhưng nói chung, bản thân microservice không nên là người dùng nếu có thể.