Thảo luận về microservice - Page 3

momotico · #21 03-12-2016, 23:07

Quote:

Originally Posted by cuoc_song

Ồ. Tức là bác lưu role tại client chăng? Vậy việc attacker tự động add thêm quyền vào local storage để khám phá các chức năng ẩn thì thế nào nhỉ?

Nhưng với những workflow phức tạp yêu cầu check quyền với data hiện thời thì bác sẽ xử lý thế nào? Ví dụ như việc chuyển hàng vào miền Nam sẽ khác với việc chuyển hàng qua miền Bắc và cần thông báo riêng 2 người khác nhau. Người này sẽ không nhận được thông báo của người kia.

Việc bác check authorization là xử lý tại từng service hay xử lý tập trung tại API Gateway ?

bạn nghiên cứu thêm về JWT nhé. dữ liệu đc lưu ở client, nhưng đc mã hóa (HS256 hoặc RS256, thông qua secret string hoặc private key). về lý thuyết thì có thể brute force để decode, nhưng ko biết đến bao giờ mới brute force xong đc thôi

việc check authorization hoàn toàn nằm ở từng microservice, check thông qua middleware

momotico · #22 03-12-2016, 23:07

Quote:

Originally Posted by cuoc_song

Ồ. Tức là bác lưu role tại client chăng? Vậy việc attacker tự động add thêm quyền vào local storage để khám phá các chức năng ẩn thì thế nào nhỉ?

Nhưng với những workflow phức tạp yêu cầu check quyền với data hiện thời thì bác sẽ xử lý thế nào? Ví dụ như việc chuyển hàng vào miền Nam sẽ khác với việc chuyển hàng qua miền Bắc và cần thông báo riêng 2 người khác nhau. Người này sẽ không nhận được thông báo của người kia.

Việc bác check authorization là xử lý tại từng service hay xử lý tập trung tại API Gateway ?

bạn nghiên cứu thêm về JWT nhé. dữ liệu đc lưu ở client, nhưng đc mã hóa (HS256 hoặc RS256, thông qua secret string hoặc private key). về lý thuyết thì có thể brute force để decode, nhưng ko biết đến bao giờ mới brute force xong đc thôi

việc check authorization hoàn toàn nằm ở từng microservice, check thông qua middleware

WasupMoFucker · #23 04-12-2016, 00:56

em junior thôi nhưng thấy gần đây cứ Microservices là đi với Golang

à mà cty bác thớt có tuyển gì làm vs data không inbox em với

RPG29 · #24 04-12-2016, 10:03

Authorization thì có thể dùng JWT và nhét quyền (permission/scope) vào token.

Vd như token có:

Code:

{
    "permissions": [
        "user_view",
        "user_create",
        "user_update"
    ]
}

Trên Middleware/API Gateway/Service lấy thông tin ra để check.

Nhưng mà cách này mình thấy chỉ phù hợp với mô hình RBAC trên từng function/feature và số lượng quyền ít, chứ số lượng mà nhiều hơn thì cái token nó lại to quá, có vẻ k ổn!?

Cái nữa là nếu yêu cầu là sử dụng ACL phân quyền trên từng domain object thì chịu, mình cũng chưa biết làm sao!?

Vd bên mình có một case thế này:
Chuỗi nhà hàng có 10 cái thì quản lý của mỗi chi nhánh chỉ dc phép truy cập chi nhánh mà mình quản lý. Tương tự với nhân viên chỉ dc phép truy cập một số chức năng và data của chi nhánh mà mình làm việc.

thuc974287 · #25 04-12-2016, 11:09

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

hallage · #26 04-12-2016, 11:24

Quote:

Originally Posted by RPG29

Authorization thì có thể dùng JWT và nhét quyền (permission/scope) vào token.

Vd như token có:

Code:

{
    "permissions": [
        "user_view",
        "user_create",
        "user_update"
    ]
}

Trên Middleware/API Gateway/Service lấy thông tin ra để check.

Nhưng mà cách này mình thấy chỉ phù hợp với mô hình RBAC trên từng function/feature và số lượng quyền ít, chứ số lượng mà nhiều hơn thì cái token nó lại to quá, có vẻ k ổn!?

Cái nữa là nếu yêu cầu là sử dụng ACL phân quyền trên từng domain object thì chịu, mình cũng chưa biết làm sao!?

Vd bên mình có một case thế này:
Chuỗi nhà hàng có 10 cái thì quản lý của mỗi chi nhánh chỉ dc phép truy cập chi nhánh mà mình quản lý. Tương tự với nhân viên chỉ dc phép truy cập một số chức năng và data của chi nhánh mà mình làm việc.

Mình không có kinh nghiệm, nghĩ theo kiểu problem solving thôi: phân nhóm permission được không ? featurePermissions và domainPermissions thay cho permissions chung như trong ví dụ trên.

_sharp_ · #27 04-12-2016, 14:38

Quote:

Originally Posted by RPG29

...
phân quyền trên từng domain object thì chịu
.....
Chuỗi nhà hàng có 10 cái thì quản lý của mỗi chi nhánh chỉ dc phép truy cập chi nhánh mà mình quản lý. Tương tự với nhân viên chỉ dc phép truy cập một số chức năng và data của chi nhánh mà mình làm việc.

Bác muốn phân quyền chi tiết đến từng Action trong Controller hay là sao ???
Tạo table:
1. User - Group User, Group User - Group.
2. Group User - Group User Action, Group User Action - Group Action.
3. Group - Group Action, Group Action - Action.

Mấy cái chi nhánh, cửa hàng, nhân viên (trưởng, phó, kế toán,..)...cứ thế mà tống data vào thôi. khi tạo 1 user nên cho nó vào 1 nhóm Group User (kể cả nó chỉ có quyền view cũng tống nó vào đó cho dễ quản lý).

Phân quyền dựa trên location, store, department, staff,...gần như giống với phân quyền trong ERP (HR, Salary,...)

// 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.

RPG29 · #28 04-12-2016, 14:50

Quote:

Originally Posted by hallage

Mình không có kinh nghiệm, nghĩ theo kiểu problem solving thôi: phân nhóm permission được không ? featurePermissions và domainPermissions thay cho permissions chung như trong ví dụ trên.

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

RPG29 · #29 04-12-2016, 15:00

Quote:

Originally Posted by _sharp_

Bác muốn phân quyền chi tiết đến từng Action trong Controller hay là sao ???
Tạo table:
1. User - Group User, Group User - Group.
2. Group User - Group User Action, Group User Action - Group Action.
3. Group - Group Action, Group Action - Action.

Mấy cái chi nhánh, cửa hàng, nhân viên (trưởng, phó, kế toán,..)...cứ thế mà tống data vào thôi. khi tạo 1 user nên cho nó vào 1 nhóm Group User (kể cả nó chỉ có quyền view cũng tống nó vào đó cho dễ quản lý).

Phân quyền dựa trên location, store, department, staff,...gần như giống với phân quyền trong ERP (HR, Salary,...)

// 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.

Thank bác, RBAC authorization này mình cũng đang áp dụng. Chỉ bị case là phân quyền trên domain object, tức là quản lý và nhân viên của chi nhánh nào chỉ có thể dc access vào data của chi nhánh đó, chi nhánh khác là k dc

Nhân tiện muốn hỏi có bác nào đã sử dụng mô hình Attribute-Based Access Control chưa nhỉ? https://www.axiomatics.com/attribute...s-control.html

_sharp_ · #30 04-12-2016, 15:09

Quote:

Originally Posted by RPG29

Attribute-Based Access Control chưa nhỉ?

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.