Cách xác thực và phân quyền trong Microservices
Cách xác th c và phân quy n trong Microservicesự ề
Xác th c (authentication, tr l i câu h i b n là ai) và phân quy n ự ả ờ ỏ ạ ề
(authorization, tr l i câu h i b n có th làm đ c gì) luôn là thành ph n ả ờ ỏ ạ ể ượ ầ
không th thi u c a m i h th ng, nh ng m c đ áp d ng thì l i tùy ể ế ủ ọ ệ ố ư ứ ộ ụ ạ
thu c vào t ng giai đo n. N u b n làm m i th ch t ch ngay t đ u, nó ộ ừ ạ ế ạ ọ ứ ặ ẽ ừ ầ
có th làm tăng đ ph c t p và làm ch m s phát tri n c a công ty. Nh ngể ộ ứ ạ ậ ự ể ủ ư
n u b n làm nó quá mu n, thì có th b n s h ng ch u nguy c b t n côngế ạ ộ ể ạ ẽ ứ ị ơ ị ấ
và r i ro t đó. V i 1 công ty e-commerce nh Tiki, r i ro đó r t hi n h u ủ ừ ớ ư ủ ấ ệ ữ
v i các h th ng liên quan t i thanh toán, ti n o (Tiki Xu), mã khuy n m iớ ệ ố ớ ề ả ế ạ
(coupon), phi u quà t ng (giftcard) và nhi u h th ng nh y c m khác…ế ặ ề ệ ố ạ ả
B t đ u t Monolithicắầừ
Tiki xu t phát là 1 h th ng monolithic, thông th ng h th ng nh v y ấ ệ ố ườ ở ệ ố ư ậ
s có 1 module chung qu n lý vi c xác th c và phân quy n, m i user sau ẽ ả ệ ự ề ỗ
khi đăng nh p s đ c c p cho 1 Session ID duy nh t đ đ nh danh. Phía ậ ẽ ượ ấ ấ ể ị
client có th l u Session ID l i d i d ng cookie và g i kèm nó trong m i ể ư ạ ướ ạ ử ọ
request. H th ng sau đó s dùng Session ID đ c g i đi đ xác đ nh danh ệ ố ẽ ượ ử ể ị
tính c a user truy c p, đ ng i dùng không c n ph i nh p l i thông tin ủ ậ ể ườ ầ ả ậ ạ
đăng nh p l n sau. ậ ầ
Khi Session ID đ c g i lên, server s xác đ nh đ c danh tính c a ng i ượ ử ẽ ị ượ ủ ườ
dùng g n v i Session ID đó, đ ng th i s ki m tra quy n c a user xem có ắ ớ ồ ờ ẽ ể ề ủ
đ c truy c p tác v đó hay không. Gi i pháp session và cookie v n có th ượ ậ ụ ả ẫ ể
s d ng, tuy nhiên ngày nay chúng ta có nhi u yêu c u h n, ch ng h n nhử ụ ề ầ ơ ẳ ạ ư
các ng d ng Hybrid ho c SPA (Single Page Application) có th c n truy ứ ụ ặ ể ầ
c p t i nhi u h th ng backend khác nhau, vì v y session và cookie l y t ậ ớ ề ệ ố ậ ấ ừ
1 server có th không s d ng đ c server khác.ể ử ụ ượ ở
Bài toán khó Microservices
Trong ki n trúc microservices, h th ng đ c chia nh thành nhi u h ế ệ ố ượ ỏ ề ệ
th ng con, đ m nh n các nghi p v và ch c năng khác nhau. M i h th ngố ả ậ ệ ụ ứ ỗ ệ ố
con đó cũng c n đ c xác th c và phân quy n, n u x lý theo cách c a ầ ượ ự ề ế ử ủ
ki n trúc Monolithic trên chúng ta s g p các v n đ sau:ế ở ẽ ặ ấ ề
M i service có nhu c u c n ph i t th c hi n vi c xác th c và phân ỗ ầ ầ ả ự ự ệ ệ ự
quy n service c a mình. M c dù chúng ta có th s d ng các th ề ở ủ ặ ể ử ụ ư
vi n gi ng nhau m i service đ làm vi c đó tuy nhiên chi phí đ ệ ố ở ỗ ể ệ ể
b o trì th vi n chung đó v i nhi u n n t ng ngôn ng khác nhau là ả ư ệ ớ ề ề ả ữ
quá l n.ớ
M i service nên t p trung vào xây d ng các nghi p v c a mình, ỗ ậ ự ệ ụ ủ
vi c xây d ng thêm logic v phân quy n làm gi m t c đ phát tri n ệ ự ề ề ả ố ộ ể
và tăng đ ph c t p c a các service.ộ ứ ạ ủ
Các service thông th ng s cung c p các interface d i d ng ườ ẽ ấ ướ ạ
RESTful API, s d ng protocol HTTP. Các HTTP request s đ c đi ử ụ ẽ ượ
qua nhi u thành ph n c a h th ng. Cách truy n th ng s d ng ề ầ ủ ệ ố ề ố ử ụ
session server (stateful) s gây khó khăn cho vi c m r ng h th ngở ẽ ệ ở ộ ệ ố
theo chi u ngang.ề
Service s đ c truy c p t nhi u ng d ng và đ i t ng s d ng ẽ ượ ậ ừ ề ứ ụ ố ượ ử ụ
khác nhau, có th là ng i dùng, 1 thi t b ph n c ng, 3rd-party, ể ườ ế ị ầ ứ
crontab hay 1 service khác. Vi c xác đ nh đ nh danh (identity) và phân ệ ị ị
quy n (authorization) nhi u ng c nh (context) khác nhau nh v y ề ở ề ữ ả ư ậ
là vô cùng ph c t p.ứ ạ
D i đây là m t s gi i pháp, k thu t và h ng ti p c n mà Tiki đã áp ướ ộ ố ả ỹ ậ ướ ế ậ
d ng cho bài toán này.ụ
Đ nh danhị
S d ngử ụ JWT
JWT (Json Web Token) là 1 lo i token s d ng chu n m dùng đ trao đ i ạ ử ụ ẩ ở ể ổ
thông tin kèm theo các HTTP request. Thông tin này đ c xác th c và đánh ượ ự
d u 1 cách tin c y d a vào ch ký. JWT có r t nhi u u đi m so v i ấ ậ ự ữ ấ ề ư ể ớ
session.
Stateless, thông tin không đ c l u tr trên server.ượ ư ữ
D d ng phát tri n, m r ng.ễ ạ ể ở ộ
Performance t t h n do server đ c thông tin ngay trong request (n u ố ơ ọ ế
session thì c n đ c storage ho c database)ầ ọ ở ặ
Mã hóa RSA cho JWT
Ph n ch ký s đ c mã hóa l i b ng HMAC ho c RSA.ầ ữ ẽ ượ ạ ằ ặ
HMAC: đ i t ng kh i t o JWT (token issuer) và đ u nh n JWT ố ượ ở ạ ầ ậ
(token verifier) s d ng chung 1 mã bí m t đ mã hóa và ki m tra.ử ụ ậ ể ể
RSA: s d ng 1 c p key, đ i t ng kh i t o JWT s d ng Private ử ụ ặ ố ượ ở ạ ử ụ
Key đ mã hóa, đ u nh n JWT s d ng Public Key đ ki m tra.ể ầ ậ ử ụ ể ể
Nh v y v i HMAC, c 2 phía đ u ph i chia s mã bí m t cho nhau, và ư ậ ớ ả ề ả ẻ ậ
đ u nh n JWT hoàn toàn có th kh i t o 1 mã JWT khác h p l d a trên ầ ậ ể ở ạ ợ ệ ự
mã bí m t đó. Còn v i RSA, đ u nh n s d ng Public Key đ ki m tra ậ ớ ầ ậ ử ụ ể ể
nh ng không th kh i t o đ c 1 JWT m i d a trên key đó. Vì v y mã hóaư ể ở ạ ượ ớ ự ậ
s d ng RSA giúp cho vi c b o m t ch ký t t h n khi c n chia s JWT ử ụ ệ ả ậ ữ ố ơ ầ ẻ
v i nhi u đ i t ng khác nhau.ớ ề ố ượ
S d ng Opaque Token khi mu n đ ki m soát phiên làm vi c t tử ụ ố ể ể ệ ố h nơ
Opaque Token (còn đ c g i là stateful token) là d ng token không ch a ượ ọ ạ ứ
thông tin trong nó, thông th ng là 1 chu i ng u nhiên và yêu c u 1 service ườ ỗ ẫ ầ
trung gian đ ki m tra và l y thông tin.ể ể ấ
Transparent Token (còn đ c g i là stateless token) thông th ng chính là ượ ọ ườ
d ng JWT, token này b n thân ch a thông tin và không c n 1 service trung ạ ả ứ ầ
gian đ ki m tra. Hãy cùng so sánh 2 lo i token này.ể ể ạ
Nh v y ta có th th y Transparent Token mang l i t c đ t t h n, đ n ư ậ ể ấ ạ ố ộ ố ơ ơ
gi n d s d ng v i c 2 phía, không phù thu c vào 1 server trung tâm đ ả ễ ử ụ ớ ả ộ ể
ki m tra. Còn Opaque Token ki m soát t t h n các phiên làm vi c c a đ i ể ể ố ơ ệ ủ ố
t ng, ch ng h n khi b n mu n thoát t t c các thi t b đang đăng nh p.ượ ẳ ạ ạ ố ấ ả ế ị ậ
OAuth 2
Các token s đ c kh i t o thông qua OAuth 2, là ph ng th c ch c th c ẽ ượ ở ạ ươ ứ ứ ự
ph bi n nh t hi n nay, mà qua đó m t service, hay m t ng d ng bên th ổ ế ấ ệ ộ ộ ứ ụ ứ
3 có th đ i đi n (delegation) cho ng i dùng truy c p vào 1 tài nguyên c aể ạ ệ ườ ậ ủ
ng i dùng n m trên 1 d ch v nào đó.ườ ằ ị ụ
OAuth 2 là chu n m , có đ y đ tài li u, th vi n t t c các ngôn ng ẩ ở ầ ủ ệ ư ệ ở ấ ả ữ
khác nhau giúp cho vi c tích h p, phát tri n d a trên nó tr nên d dàng và ệ ợ ể ự ở ễ
nhanh chóng.
****
Ki n trúc cho xác th c và phânế ự quy nề
Sau khi đã có đ nh danh và giao th c dùng đ giao ti p, câu h i ti p theo là ị ứ ể ế ỏ ế
c n tr l i câu h i đ i t ng v i đ nh danh đó có quy n th c hi n 1 hành ầ ả ờ ỏ ố ượ ớ ị ề ự ệ
có thể bạn quan tâm
Nghiên cứu về khái niệm quyền con người, sự khác nhau trong việc tiếp...
20
872
4.380
Báo cáo, luận văn khác
20
(New)
Luận văn: Giới thiệu, quản lý User và phân quyền trong UBUNTU SERVER
87
706
284
Kỹ thuật
87
(New)
Hóa đơn ghi cách quyển xử lý như thế nào?
2
596
268
Kế toán, kiểm toán
2
(New)
Đề tài: Các giao thức bảo mật dùng trong VPN, cách cấu hình VPN bằng p...
79
823
386
Kỹ thuật
79
(New)
Về việc ủy quyền và Mẫu Giấy Ủy quyền - Dành cho cá nhân
2
773
325
Mẫu đơn từ
2
(New)
Nghiên cứu tìm hiểu lý luận về thị trường chứng khoán, quyền chọn và ý...
87
1.038
473
Thạc sĩ cao học
87
(New)
Tổng quan về quyền chọn tiền tệ và thị trường quyền chọn tiền tệ và đá...
52
746
536
Kinh tế quản lý
52
(New)
Cách mở đầu và kết thúc một cuộc đàm phán
7
1.571
460
Kỹ năng đàm phán
7
(New)
thông tin tài liệu
Xác thực (authentication, trả lời câu hỏi bạn là ai) và phân quyền (authorization, trả lời câu hỏi bạn có thể làm được gì) luôn là thành phần không thể thiếu của mọi hệ thống, nhưng mức độ áp dụng thì lại tùy thuộc vào từng giai đoạn.
Mở rộng để xem thêm
từ khóa liên quan
tài liệu mới trong mục này
tài liệu hot trong mục này
tài liệu giúp tôi
Nếu bạn không tìm thấy tài liệu mình cần có thể gửi yêu cầu ở đây để chúng tôi tìm giúp bạn!
×
