Mọi người đều cảm thấy thích thú về Microservices, nhưng việc cài đặt trong thực tế là khá khó. Có lẽ lý do chính là mọi người không hiểu rõ rằng làm thế nào mà các services có thể giao tiếp với nhau, đặc biệt hơn là lưu trữ được thông tin danh tình người dùng và quản lý truy cập trên một biển các services độc lập.

Không giống như cấu trúc nguyên khối truyền thống mà có lẽ chỉ có một cổng thông tin bảo mật duy nhất thì microservice đặt ra nhiều vấn đề. Liệu rằng mỗi service nên có tường lửa an ninh của chính nó? Làm thế nào để có thể để danh tính người dùng đc phân tán giữa các service và khắp toàn hệ thống? Phương thức nào là hiệu quả nhất khi trao đổi dữ liệu người dùng?

Có những kĩ thuật thông minh mà làm nền tảng cho các công nghệ phổ biến hiện nay không chỉ thực hiện trên toàn bộ hệ thống của bạn. Trong bài báo này, tôi sẽ chỉ ra làm thế nào để thực hiện dòng OAuth và OpenID Connect mà sử dụng JSON Web Token để đạt được kết quả cuối cùng trong việc tạo một cơ chế xác thực được phân tán cho các microservices-Một quá trình quản lý danh tính người dùng.

I. Microservice là gì?

Với những người không quan tâm lắm về xu hướng web gần đây, thì cách tiếp cận thiết kế micorservice là một cách để kiến trúc web service thành các thành phần độc lập đảm nhiệm chức năng chuyên biệt. Các thành phần được thiết kế để phù hợp với một chức năng nhất định và được deploy như các môi trường riêng biệt. Việc biên dịch lại các thành phần một các độc lập có nghĩa là việc phát triển và mở rộng sẽ dễ dàng hơn trong một hệ thống sử dụng microsercives.

Trái ngược lại với cấu trúc trên, cách tiếp cận nguyên khối truyền thống (traditional monolithic approach) sẽ hợp nhất tất cả các thành phần của web vào trong một hệ thống. Nhược điểm của thiết kế nguyên khối này là các vòng kiểm soát phiên bản là khó, thêm vào đó là khả năng mở rộng là chậm. Toàn bộ hệ thống phải deploy liên tục mỗi khi sửa, thêm mới chứ năng cho hệ thống.

Xu hướng microservices hóa có thể ảnh hưởng đáng kể toàn ngành, nó cho phép các tổ chức SaaS deploy nhiều các service nhỏ mà không còn phụ vào việc sửa chữa các hệ thống lớn.

II. Các vấn đề với Microservice

Vấn đề mà chúng ta đối mặt là các Microservices không thích hợp với mô hình truyền thống của việc kiểm soát xác định danh tính. Trong bảo mật của hệ thống nguyên khối thực hiện đơn giản theo các bước:

1. Tìm ra ai được gọi.
2. Truyền các thông tin đến các thành phần khác khi được gọi.
3. Lưu trữ thông tin người đùng ở kho dữ liệu.

Khi mà các thành phần cùng nằm trong một khối thì chúng có lẽ sẽ cùng chung tường lửa bảo mật. Chúng có chung trạng thái của người dùng khi chúng nhận nó và cùng truy cập vào kho dữ liệu giống nhau.

Nếu kĩ thuật tương tự được áp dụng cho từng microservices thì hiển nhiên sẽ không hiệu quả. Việc có tính bảo mật nằm ở từng service là không cần thiết. Nó sẽ bao hàm việc gọi Authentication Service để gắn đối tượng để xử lý yêu cầu và đáp ứng mọi thực thể.

III. Hướng giải quyết: OAuth như một giao thức đại biểu (A Delegation Protocol)

Có một phương pháp mà cho phép kết hợp những ưu điểm của deployment độc lập với sự dễ dàng của xác định danh tính. Jacob Ideskog của Twobo Technologies tin rằng để hoàn thành, OAuth này nên được diễn tả không như Authentication và cũng không như Authorization mà là Delegation.

Trong thực tế trên thế giới thì delegation là nơi mà bạn có thể ủy nhiệm ai đó làm gì cho bạn. Còn trong lĩnh vực web là có nhưng nó cũng có nghĩa nó có khả năng đề nghị, chấp thuận, từ chối của việc trao đổi dữ liệu. Việc cho rằng OAuth như một giao thức Delegation có thể giúp trong việc tạo ra các Microservices và APIs có khả năng mở rộng.

Để hiểu quá trình này chúng ta sẽ bố trí một flow OAuth chuẩn cho một trường hợp đơn giản. Giả sử chúng ra cần truy cập vào một tài khoản mail người dùng trong một ứng dụng đơn giản. OAuth có 4 nhân tố chính:

• Resource Owner (RO): user.
• Client: the web or mobile app.
• Authorization Service (AS): OAuth 2.0 server.
• Resource Server(RS): Nơi mà service thứ tế được lưu trữ.

IV. Một ví dụ đơn giản của một luồng OAuth 2

Trong ví dụ trên, ứng dụng(the Client) cần truy cập vào tài khoản mail(the Resource Server) để lấy các mail trước khi nó có thể tổ chức chúng để tạo ra ra hệ thống thông báo. Trong một luồng OAuth đơn giản, một quá trình phê duyệt sẽ qua các bước:

1. Client yêu cầu truy cập đến Resource Server bằng việc gọi Authorization Server
2. Authorization Server điều hướng để xác nhận người dùng (thường được thực hiện trong browser). Đây là đăng nhập cần thiết vào một Authorization Server
3. Authorization Server sẽ kiểm tra thông tin người dùng và cung cấp một Access Token cho Client. Access Token sẽ đc sử đụng để lấy dữ liệu từ Resource Sever
4. Client sẽ gửi Token đến Resource Server
5. Resource Sever sẽ hỏi Anthorization Server liệu Token có đúng ko?
6. Authorization Server sẽ kiểm tra Token và trả lại thông tin thích hợpc ho Resource Server như thời gian sống của Token, Token thuộc về ai...
7. Resource Server sẽ cung cấp dữ liệu cho Client.

Một nhân tố quan trong khác để lưu ý bên trong luông là Client không biết gì về người dùng ở tại bước này. Dù đây là một sự trao đổi bảo mật nhưng dữ liệu token là không hữu ích cho chính client. Sự trao đổi cung cấp sư truy nhập cho client chứ không phải thông tin người dùng.

V. Luồng kết nối OpenID

Bây giờ giả sử chúng ta muốn cải thiện phía mail service client nên nó không chỉ nằm ở việc tổ chức các mail của bạn mà còn nằm ở chỗ lữu chữ chúng ra sao và dịch chúng thành các ngôn ngữ khác nhau. Trong trường hợp này client sẽ muốn có thêm thông tin dữ liệu người dùng và giữ chúng trong chính session người dùng.

Có thể cung cấp cho client những thứ hơn cả token mà được cung cấp bởi luồng OAuth thì phải sử dụng thêm một luồng mà được định nghiwax trong OpenID Connect. Trong quá trình này Authorization Server mà được gọi bởi OpenID Connect Provider(OP) sẽ trả ra một ID Token cùng với Access Token cho client. Luồng của nó như sau:

1. Client yêu cầu truy cập đến Resource Server bởi lời gọi Open ID Connect từ Authorization Server.
2. Authorization Server sẽ điều hướng để cho phép user xác thực.
3. Authoriztion Server sẽ kiểm tra thông tin người đùng và cung cấp một Access Token và một ID Token đến client
4. Client sử dụng ID Token để nang trả nhiệm người dùng và lưu trữ thông tin vào trong chính session của nó.
5. Clien sẽ gửi Access Token để lấy Resource Server
6. Resource Server sẽ gửi dữ liệu về cho Client

ID token sẽ gồm có các thông tin về người dùng như sự chứng thực, tên, mail và các dữ liệu khác của người dùng. ID token này có dạng là một JSON Web Token(JWT) mà một mã biên dịch của tài liệu JSON. Tài liệu bao gồm header, body và một chữ kí (JWT) được gắn vào message. Data + Signature = JWT.

Việc sử dụng JWT thì bạn có thể truy cập được các phần của sự chứng nhận, kiểm tra chữ kí và hiểu được rằng phiên xác thực này đã được ban hành xác minh rằng người dùng đã được chứng thực. Một kía cạnh quan trọng của phương pháp này là rằng ID Token đã được thiết lập giữa Authorization Server/Open ID Connect Provider và Client.

VI. Kết luận

Bằng việc sử dụng OAuth với OpenID Conect và bằng việc tạo một chuẩn dựa trên kiến trúc JWT thì kết quả cuối cùng là một cơ chế xác minh được phân tán.

Bài viết tham khảo từ

http://nordicapis.com/how-to-control-user-identity-within-microservices/