robertmarkdown
Senior Member
Thím có thể giải thích rõ hơn chỗ này giúp e đc k nhỉ? Auth Service 1 database riêng thì Order Service vẫn cần gọi sang Auth để authorized chứ nhỉ, vì token chỉ chứa mỗi userID mà?
thắc mắc Authorization trong microservice như nào cho hợp lý
- Thread starter losser50cm
- Start date
BanhXe0_
Đã tốn tiền
Cho minh hoi chổ in đậm thì nên authoz như nào nhỉ , minh vẫn ko hình dung dc ?
Ngữ cãnh như bạn mô tả, khi đã authen rồi ,qua gateway, thì khi vào trong service.order, thì ko biết bạn làm sao với cái access_token để xác thực user này nếu bạn chỉ ở trong service.order ? Trong khi chỉ có thằng service.auth mới decode dc cái access_token đó
Kopi Luwak
Senior Member
Topic hay, đồng ý với quan điểm của bác Itachi
empty-wharf
Junior Member
Mình có thắc mắc, nếu hacker đã vào được 1 internal service rồi thì làm sao có cách nào tự động phát hiện được, lúc này nó giữ toàn quyền cũng như toàn bộ environments, cũng phải chặn thủ công thôi mà đúng k
Nhưng mình đồng ý việc xác thực giữa các service là cần thiết, nó đảm bảo 1 service chỉ có quyền gọi tới 1 số services nhất định
Nhưng mình đồng ý việc xác thực giữa các service là cần thiết, nó đảm bảo 1 service chỉ có quyền gọi tới 1 số services nhất định
Last edited:
telbook
Senior Member
Topic authz(Authorization) mà toàn nói về authn(Authentication) 
Insider job bị phát hiện ra là đi tù chứ không như bị tấn công ẩn danh từ ngoài nên ít xảy ra, kết hợp authz policy ngon thì cảnh báo được ngay (VD: vi phạm truyền truy cập bị lưu logs, nhiều lần thì bị revoke auth/report). Nên mấy ông insider có dám tấn công khi không hiểu rõ hệ thống không? Còn hiểu cả hệ thống thì mấy ông đấy chắc bị camera monitor 24/24
Các service có kết nối ra internet thì phải có authn, và có nhiều cách google đầy rồi (plain text, token, bcrypted, public-key signature system...). Còn intranet chỉ dùng mấy cái authn đơn giản thôi. Bị tấn công vẫn có authz bảo vệ như trên.
Cty cùi intranet còn chẳng có authn authz gì ấy chứ
Insider job bị phát hiện ra là đi tù chứ không như bị tấn công ẩn danh từ ngoài nên ít xảy ra, kết hợp authz policy ngon thì cảnh báo được ngay (VD: vi phạm truyền truy cập bị lưu logs, nhiều lần thì bị revoke auth/report). Nên mấy ông insider có dám tấn công khi không hiểu rõ hệ thống không? Còn hiểu cả hệ thống thì mấy ông đấy chắc bị camera monitor 24/24
Các service có kết nối ra internet thì phải có authn, và có nhiều cách google đầy rồi (plain text, token, bcrypted, public-key signature system...). Còn intranet chỉ dùng mấy cái authn đơn giản thôi. Bị tấn công vẫn có authz bảo vệ như trên.
Cty cùi intranet còn chẳng có authn authz gì ấy chứ
WhatEverName
Junior Member
Insider bị hacked rồi tụi hacker dùng máy insider để tấn công internal system nha bác. Đây là phương thức tấn công rất phổ biến.Topic authz(Authorization) mà toàn nói về authn(Authentication)
Insider job bị phát hiện ra là đi tù chứ không như bị tấn công ẩn danh từ ngoài nên ít xảy ra, kết hợp authz policy ngon thì cảnh báo được ngay (VD: vi phạm truyền truy cập bị lưu logs, nhiều lần thì bị revoke auth/report). Nên mấy ông insider có dám tấn công khi không hiểu rõ hệ thống không? Còn hiểu cả hệ thống thì mấy ông đấy chắc bị camera monitor 24/24
Các service có kết nối ra internet thì phải có authn, và có nhiều cách google đầy rồi (plain text, token, bcrypted, public-key signature system...). Còn intranet chỉ dùng mấy cái authn đơn giản thôi. Bị tấn công vẫn có authz bảo vệ như trên.
Cty cùi intranet còn chẳng có authn authz gì ấy chứ
telbook
Senior Member
Cái đó không gọi là insider job đâu, người ngoài chiếm điều khiển máy của ông bên trong vẫn tính là external threats
gazer000
Đã tốn tiền
RBAC mà mớ permission rắc rối không nhồi được vào token thì theo mình là ở gateway chọc 1 phát vào auth/authz, cache mớ thông tin đó lại rồi khi xuống service thì tất cả dùng chung 1 bộ dependency có config filter, bó cẩn thì forward lại cả token xuống (không thả rông thông tin trong internal), filter verify lại signature rồi cầm userId đó request đến 1 endpoint trả về thông tin được cache bên trên
evileyes1993
Senior Member
Thím có thể giải thích rõ hơn chỗ này giúp e đc k nhỉ? Auth Service 1 database riêng thì Order Service vẫn cần gọi sang Auth để authorized chứ nhỉ, vì token chỉ chứa mỗi userID mà?
Khi authen xong sẽ đến phần authorized đúng ko. Và mình sẽ authorized dc ở service order luôn vì trong database của order service (VD "order database") đã có dữ liệu của user luôn rồi.
Câu hỏi là dữ liệu user này lấy từ đâu? Nó lấy từ database "user".
VD Khi mà bạn tạo một user mới ở Auth Service gắn với db "user", sau khi tạo trong db "user" sẽ có một event trigger từ message broker (kafka chẳng hạn), emit event từ "Auth Service" tới "Order Service" dữ liệu của thằng user đó -> "Order Service" thêm vô "order database" thằng user đấy.
Khi có request tới order service, dữ liệu thằng đấy đã có luôn rồi -> ko cần phải call qua auth service nữa -> đỡ tốn một round trip, check trực tiếp ở đây -> delay giảm tối đa.
Nếu đặt trong ngữ cảnh chục tới trăm service thì một cái roundtrip này khá valuable về performance đấy. Việc dùng message broker để emit event cũng khá phổ biến trong kiến trúc micro-service nữa...
- Vẫn authen ở api gateway như bt.
- Lúc request pass gateway tới internal service, vd service order thì sẽ authorized tại service này.
- Service order có thể authorize dc luôn vì nó đã có luôn dữ liệu của user lấy từ database của Auth Service rồi, ko tốn thêm roundtrip gọi sang Auth Service mà xử lý dc ngay tại chỗ => delay giảm tối đa, mà vẫn authorized được ở "internal service level" để bảo mật.
- Service order có dữ liệu của user qua phương pháp data replication, có thể sử dụng Kafka hay RabbitMQ để emit event.
Hero Kun
Senior Member
theo mình ghỉ cái đó làm chứ năng đổi pass thôi, còn trong mỗi service có khi phải dùng lại bảng user ở trong các service khác để mình còn lấy query các data của user.
redbaronever
Junior Member
Mấy bác bàn security đúng ngay ý em đang quan tâm.
Bác nào có tài liệu để em build thử từ đầu tới cuối đúng chuẩn đúng bài spring security, microservices, kafka về vấn đề này mà đảm bảo bảo mật ko ạ
Bác nào có tài liệu để em build thử từ đầu tới cuối đúng chuẩn đúng bài spring security, microservices, kafka về vấn đề này mà đảm bảo bảo mật ko ạ
Dangpech
Junior Member
e đang đọc cuốn microservices security in action, trước thì có cuốn spring security in action hay phết. Đọc mỗi documentation thì lú quá
)
Hero Kun
Senior Member
có mấy kênh youtube đó, vào làm theo là ok.e đang đọc cuốn microservices security in action, trước thì có cuốn spring security in action hay phết. Đọc mỗi documentation thì lú quá
Love U So Much
Senior Member
bên e hiện tại là làm thế này, có 1 service keycloak để auththentication, tạo jwt token, role, username ...
khi có request thì có 1 con service khác decode jwt ở cookie / authorization header, và nó tạo ra 1 header username, 1 header roles, cho các service khác cần thì dùng
các service khác cần authorization thì tự đọc header
khi có request thì có 1 con service khác decode jwt ở cookie / authorization header, và nó tạo ra 1 header username, 1 header roles, cho các service khác cần thì dùng
các service khác cần authorization thì tự đọc header
Hero Kun
Senior Member
mình trước cũng dùng con keycloak nhưng cài keycloak lên sever lâu lâu bị lỗi mất hết data nên tự viết cho nhanh.
Similar threads
