Microservices xác thực

Question

Context

Tôi có nhiều dịch vụ như:

• tài khoản (LDAP hoặc thư mục hoạt động vv ...)
• Thanh toán
• Kế hoạch
• vv ...
• Xác thực

tôi cần phải kết nối trên microservices tôi Sử dụng OAuth2.0, cho đầu, sử dụng tên đăng nhập chuẩn/mật khẩu (tôi sử dụng dữ liệu của riêng tôi, và không gettint một máy chủ chân thứ ba)

Vấn đề

Theo những bức ảnh này:

Bước 1

Bước 2

Làm thế nào tôi có thể xử lý kiểm soát access_token hoặc kiểm soát quyền truy cập, các dịch vụ khác của tôi hơn authmicroservice?

Answer 1

có một hướng dẫn và mô tả dòng chảy xác thực trong microservices trong activator của chúng tôi, đó là trong Scala - http://www.typesafe.com/activator/template/reactive-microservices (nguồn: https://github.com/theiterators/reactive-microservices)

---

Ý tưởng cơ bản là: Bạn cần phải xác nhận tính xác thực của thẻ auth cho mọi yêu cầu. Bạn có thể:

- làm điều đó trong một proxy (gateway)

- làm điều đó bên trong microservice thanh toán

---

Những gì chúng ta có xu hướng làm là: để xác nhận Auth-Mã bên trong mọi dịch vụ nhỏ của khách hàng.

- Chúng tôi giữ thông tin Auth-Token to User trong phiên bản Redis.

- Dịch vụ khách hàng phải đối mặt với yêu cầu thẩm redis nếu dấu hiệu này là hợp lệ

- Redis trả về một số chuỗi JSON rằng chúng ta có thể sử dụng như là một dữ liệu người dùng cho phép tiếp tục.

Vì vậy, dòng chảy phía máy chủ trông như thế này

get("projects/"/Segment) { projectName => 
    getHeader("Auth-Token") { authToken => 
    Redis.get("auth:token:#{authToken}").map { userJson => 
     if(userJson("projects").include(projectName)) { 
     ...processSth... 
     Ok 
     } else { 
     Unauthorized 
     } 
    } 
    } 
} 

Answer 2

Có thể tạo ra dịch vụ Auth riêng biệt để cung cấp access_token như bạn thấy ở bước 1. Nhưng trong API Gateway mỗi dịch vụ sẽ cần thiết để gọi đó là dịch vụ auth để xác thực mã thông báo.Cách tốt nhất để áp dụng quy trình oauth trong API Gateway mà tôi đang sử dụng cũng như cho sản phẩm của tôi và cách tiếp cận này cũng được giải thích trong nhiều bài viết. cho phép xem hình ảnh bên dưới.

Trong góc độ kỹ thuật, Nó có thể đơn giản là một phần của mã (chức năng) mà xử lý tiêu đề yêu cầu để xác minh dấu hiệu cung cấp như xác thực oauth, mà có thể xử lý trong mã hoặc bằng cách truy cập cơ sở dữ liệu riêng trước khi nó chuyển tiếp yêu cầu đến điểm cuối của dịch vụ.

Bạn có thể thực hiện theo một phương pháp để cung cấp xác thực, bảo mật và gửi yêu cầu đến điểm cuối bằng dịch vụ Cổng API nâng cao. Có câu hỏi đã được hỏi tại stackoverflow here, Nhưng những gì tôi thấy dễ làm theo là 3 hoặc 4 loạt hướng dẫn bạn sẽ tìm thấy here

Xem hình ảnh rõ ràng về cách sử dụng API Gateway của bạn trước khi tập trung vào các dịch vụ nhỏ.

Answer 3

Tùy thuộc vào cách bạn đang cấu trúc các dịch vụ vi mô của mình, bạn cũng có thể tận dụng lợi thế của bố cục.

Vì bạn đã có dịch vụ xác thực, bạn có thể sử dụng dịch vụ này trong dịch vụ Thanh toán để kiểm tra tính xác thực của yêu cầu trước khi xử lý yêu cầu đó.

Ví dụ, nếu bạn đang sử dụng một nền tảng như StdLib (chúng tôi sử dụng này trong nhà):

// Billing 
const lib = require('lib'); 

module.exports = function(params, callback) { 
    lib.user.isAuthenticated(params, function(err, user) { 
    if (err) return callback(err); 
    // Do stuff with user, process billing 
    }); 
}; 

Điều này có thể không phải là một ý tưởng tuyệt vời dành cho bạn nếu bạn luôn sử dụng HTTP để giao tiếp giữa các chức năng (vì điều này sẽ thêm có thể là một 200-300ms tốt cho yêu cầu của bạn). Nhưng StdLib tải lên một vài dịch vụ trong cùng một khu vực và bạn có thể truy cập chúng về cơ bản giống như các hàm giải quyết cho vấn đề đó (ít nhất, cho đến nay chúng ta đã thấy).

Answer 4

Để quản lý xác thực trong kiến ​​trúc microservices, bạn phải có một quan điểm khác.

Hãy nhớ rằng khi bạn làm việc trên một khối nguyên khối, bạn đã có một quy trình xác thực duy nhất.

Ví dụ trong ứng dụng PHP, bạn tìm người dùng của mình trong cơ sở dữ liệu với thông tin đăng nhập tương ứng, sau đó bạn đã tạo phiên mà người dùng được "xác thực".

Với microservices, quy trình làm việc cũng giống nhau. Điều duy nhất thay đổi ngay bây giờ là bạn không thể mở một phiên trong các dịch vụ khác nhau. Hơn nữa, bạn không cần phải có được người dùng được xác thực. Bạn chỉ cần chắc chắn rằng anh ta được phép thực hiện cuộc gọi hiện tại trên các dịch vụ nhỏ của bạn.

Nhờ oauth2, có access_token hợp lệ cung cấp cho bạn thông tin này.

Điều này sẽ trả lời phần giao diện người dùng. Trong phần phụ trợ (ý tôi là phía sau cổng api), bạn không nên quản lý access_token vì nó không liên quan đến microservices. Bạn có thể sử dụng một phím chức năng để tìm bất kỳ thông tin nào liên quan đến người dùng bên trong các dịch vụ nhỏ như một uuid chẳng hạn.

Để nhận được uuid trong khi sử dụng oauth2, tôi cũng khuyên bạn nên sử dụng kết nối openid. Người dùng có giao thức này để quản lý thông tin người dùng cụ thể và nó cung cấp cho bạn quyền truy cập vào một điểm cuối cụ thể "/ userinfo".

Hy vọng giản đồ này sẽ làm cho câu trả lời này rõ ràng hơn.