Chiến lược xác thực microservice

Tôi đang gặp khó khăn trong việc lựa chọn chiến lược xác thực hợp lý / an toàn cho kiến ​​trúc microservice. Bài đăng SO duy nhất tôi tìm thấy về chủ đề này là bài này: Đăng nhập một lần trong Kiến trúc microservice

Ý tưởng của tôi ở đây là có trong mỗi dịch vụ (ví dụ: xác thực, nhắn tin, thông báo, hồ sơ, v.v.) một tham chiếu duy nhất cho mỗi người dùng (khá logic sau đó là của anh ta user_id) và khả năng có được người dùng hiện tại idnếu đăng nhập.

Từ các nghiên cứu của tôi, tôi thấy có hai chiến lược khả thi:

1. Kiến trúc dùng chung

Trong chiến lược này, ứng dụng xác thực là một dịch vụ khác. Nhưng mỗi dịch vụ phải có khả năng thực hiện chuyển đổi session_id=>user_id vì vậy nó phải đơn giản. Đó là lý do tại sao tôi nghĩ về Redis, sẽ lưu trữ khóa: giá trị session_id:user_id.

2. Kiến trúc tường lửa

Trong chiến lược này, lưu trữ phiên không thực sự quan trọng, vì nó chỉ được xử lý bởi ứng dụng xác thực. Sau đóuser_id có thể được chuyển tiếp đến các dịch vụ khác. Tôi đã nghĩ về Rails + Devise (+ Redis hoặc mem-cacheed, hoặc lưu trữ cookie, v.v.) nhưng có rất nhiều khả năng. Điều duy nhất quan trọng là Service X sẽ không bao giờ cần xác thực người dùng.

Làm thế nào để hai giải pháp so sánh về:

• Bảo vệ
• sự mạnh mẽ
• khả năng mở rộng
• dễ sử dụng

Hoặc có thể bạn sẽ đề xuất một giải pháp khác mà tôi chưa đề cập ở đây?

Tôi thích giải pháp số 1 tốt hơn nhưng chưa tìm thấy nhiều triển khai mặc định sẽ bảo đảm cho tôi trong thực tế là tôi đang đi đúng hướng.

Tôi hy vọng câu hỏi của tôi không bị đóng cửa. Tôi thực sự không biết nơi nào khác để hỏi nó.

Cảm ơn trước

Dựa trên những gì tôi hiểu, một cách tốt để giải quyết nó là sử dụng giao thức OAuth 2 (bạn có thể tìm thêm một chút thông tin về nó trên http://oauth.net/2/ )

Khi người dùng của bạn đăng nhập vào ứng dụng của bạn, họ sẽ nhận được mã thông báo và với mã thông báo này, họ sẽ có thể gửi đến các dịch vụ khác để xác định chúng trong yêu cầu.

Ví dụ về thiết kế dịch vụ xích

Tài nguyên:

• http://presos.dsyer.com/decks/microservice-security.html
• https://github.com/intridea/oauth2
• https://spring.io/guides/tutorials/spring-security-and-angular-js/

Câu trả lời ngắn: Sử dụng xác thực dựa trên mã thông báo loại Oauth2.0, có thể được sử dụng trong bất kỳ loại ứng dụng nào như ứng dụng web hoặc ứng dụng di động. Trình tự các bước liên quan đến một ứng dụng web sẽ là

1. xác thực với nhà cung cấp ID
2. giữ mã thông báo truy cập trong cookie
3. truy cập các trang trong webapp
4. gọi các dịch vụ

Sơ đồ dưới đây mô tả các thành phần cần thiết. Một kiến ​​trúc như vậy tách biệt web và apis dữ liệu sẽ cho khả năng mở rộng, khả năng phục hồi và ổn định tốt

Mẫu cổng API nên được sử dụng để triển khai điều này bằng OpenID Connect. Người dùng sẽ được IDP xác thực và sẽ nhận được mã thông báo JWT từ máy chủ ủy quyền. Bây giờ hệ thống cổng API có thể lưu trữ mã thông báo này trong cơ sở dữ liệu Redis và đặt cookie trên trình duyệt. API gateway sẽ sử dụng cookie để xác thực yêu cầu của người dùng và sẽ gửi mã thông báo đến microservice.

API Gateway hoạt động như một điểm vào duy nhất cho tất cả các loại ứng dụng khách như ứng dụng khách java script công khai, ứng dụng web truyền thống, ứng dụng di động gốc và ứng dụng khách của bên thứ ba trong kiến ​​trúc microservice.

Bạn có thể tìm thêm chi tiết về nó trên http://proficientblog.com/microservice-security/

bạn có thể sử dụng máy chủ idenitty 4 cho mục đích xác thực và ủy quyền

bạn phải sử dụng Kiến trúc tường lửa do đó bạn có nhiều quyền kiểm soát hơn về tính bí mật, mạnh mẽ, khả năng mở rộng và dễ sử dụng