[cuoc_song]

Originally Posted by RPG29

Thực ra thì cũng đã suy nghĩ vấn đề này. Security nói chung là cross-cutting concern, cho nên đặt ở nhiều chỗ có lẽ cũng chấp nhận được.

1. Với authorization trên domain object thì thực hiện ở mức service. Vì domain object là data thuộc service đó cho nên k nơi nào tốt hơn check authorization trong chính service.

2. Với authorization trên function/feature thì có thể thực hiện ở mức service hoặc ngay trên API Gateway.

3. Trường hợp thực hiện check authorization trên API Gateway.

3a. Nếu permission/scope ít thì cứ nhét tất vào token cho khỏe. Lúc request đến thì cứ check resource cần truy cập và permission trong token là xong.

3b. Nếu permission/scope "nhiều", cảm thấy token to quá thì có thể đẻ ra một thằng authorization-service. API Gateway gọi thằng authorization-service này để kiểm tra trước khi thực sự gọi xuống các service khác. Data ở service này có thể cache lại nên có lẽ k lo lắng lắm về performance, chỉ có điều giờ hệ thống sẽ có 2 thằng SPOF là API Gateway & Authorization-service.

Mới nghĩ dc nhiêu đó, chưa có cách nào hay hơn

Mình cũng gặp vấn đề tương tự. Nhưng mà với việc perrmisson cho domain object thì mình buộc phải fix các role trước để check logic. còn với ACL check function thì có thể tùy biến role. Cơ mà lại phát sinh vấn đề là khi logic thay đổi 1 chút lại thay đổi tất cả các role đã có lại phải đi phân quyền function lại. Lại 1 vòng test từ đầu đến cuối.

Kinh nghiệm của bác với permission của domain object là gì vậy?

[4nh7i3m]

Theo ngu ý của tui thôi là Authorization phải thực hiện trên Server ở bất kỳ Action nào. Ở client có thể lưu giữ thông tin về Role và các Permissions nhưng chỉ để giảm tải cho server về phần đọc permissions thôi. Nhưng trước khi thực hiện bất kỳ tác vụ nào trên server đều phải được authorized (permitted/denied). Dù là client có siêu cấp mã hóa thế nào đi chăng nữa thì "never trust user input" là quy tắc bất di bất dịch.

[cuoc_song]

Originally Posted by _sharp_

Rồi bác, cách đây 4 năm.
Có 2 chi nhánh ở SG và HN (gọi là location), ở mỗi location lại có các chi nhánh (region), mỗi 1 region lại có các phòng ban (department), phòng ban lại có staff (nhân viên trưởng phòng, phó phòng,...). Giám đốc/phó giám đốc ở region/location. Từng location/rẹgion/department và director, staff chỉ được thực hiện 1 vài action trên hệ thống ứng với scope của mình. Project yêu cầu phân quyền kiểu thế.

Còn data thì nếu bác dùng chung 1 DB thì cứ thêm field để biết là data từ đâu vào.
Còn nếu mỗi 1 cửa hàng dùng 1 DB riêng, data sync về 1 DB tập trung thì nhẹ nhàng hơn.

Bác có tài liệu design và implement cho cái ABAC không cho mình xin với

[_sharp_]

Originally Posted by 4nh7i3m

d (permitted/denied). Dù là client có siêu cấp mã hóa thế nào đi chăng nữa thì "never trust user input" là quy tắc bất di bất dịch.

Originally Posted by _sharp_

Thêm nữa, trong token có user_id là được, API check quyền xong trả về message access deny và status code là xong, chứ mình ko thích nhét permission vào trong token.

ahihi, "đồng da^m" đây rồi

[thuc974287]

Originally Posted by thuc974287

Cho em hỏi về cái authorization tý, luồng xử lý web api thế nào khi client(web or mobile) đăng nhập các provider như facebook, google

Hiện tại em google thì thấy nó như thế này: client đăng nhập các provider get về profile, access token, refresh token (nếu có). Client request đống trên về web api, web api dùng access token request lại lên provider, nhận lại kết quả và so sánh xem profile có trùng khớp với profile của client gửi hay không

Như thế là đúng chưa các bác

Ai giúp em vấn đề này với

[RPG29]

Originally Posted by cuoc_song

Mình cũng gặp vấn đề tương tự. Nhưng mà với việc perrmisson cho domain object thì mình buộc phải fix các role trước để check logic. còn với ACL check function thì có thể tùy biến role. Cơ mà lại phát sinh vấn đề là khi logic thay đổi 1 chút lại thay đổi tất cả các role đã có lại phải đi phân quyền function lại. Lại 1 vòng test từ đầu đến cuối.

Kinh nghiệm của bác với permission của domain object là gì vậy?

Bên mình chủ yếu là RBAC trên chức năng. Map Controller - Action - Role thôi.
Còn case phân quyền trên domain object là case quản lý + nhân viên của mỗi chi nhánh chỉ dc truy cập data của chi nhánh đó. Hiện ko có implement ACLmà dùng Voter trên object, ko dc linh hoạt như ACL nhưng bước đầu vậy là đủ.

Bác nào có ref tham khảo implement ABAC share ae với, thấy thằng này thú vị quá

[RPG29]

Originally Posted by thuc974287

Cho em hỏi về cái authorization tý, luồng xử lý web api thế nào khi client(web or mobile) đăng nhập các provider như facebook, google

Hiện tại em google thì thấy nó như thế này: client đăng nhập các provider get về profile, access token, refresh token (nếu có). Client request đống trên về web api, web api dùng access token request lại lên provider, nhận lại kết quả và so sánh xem profile có trùng khớp với profile của client gửi hay không

Như thế là đúng chưa các bác

Client chạy lên oauth2 provider để lấy access_token. Bên trong access_token có nhúng các quyền truy cập mà app đã yêu cầu (email, friends, liked...).

Client submit access_token lên server, server ném access_token mà client truyền lên qua oauth2 provider để verify. Nếu thành công thì sẽ get dc những data tương ứng với quyền trên access_token.

[cuoc_song]

Nếu có nhiều instance của 1 service tại các IP khác nhau thì các bác đang routing bằng cái gì vậy ?? DNS LB chăng ?

[thuc974287]

Originally Posted by RPG29

Client chạy lên oauth2 provider để lấy access_token. Bên trong access_token có nhúng các quyền truy cập mà app đã yêu cầu (email, friends, liked...).

Client submit access_token lên server, server ném access_token mà client truyền lên qua oauth2 provider để verify. Nếu thành công thì sẽ get dc những data tương ứng với quyền trên access_token.

Thanks bác

[cuoc_song]

không bác nào quan tâm cái này nữa à ?