Ở bất kỳ công ty lớn nào, và Tập đoàn bán lẻ X5 cũng không ngoại lệ, khi công ty phát triển, số lượng dự án yêu cầu sự ủy quyền của người dùng ngày càng tăng. Theo thời gian, cần phải có sự chuyển đổi liền mạch của người dùng từ ứng dụng này sang ứng dụng khác và sau đó cần sử dụng một máy chủ Single-Sing-On (SSO). Nhưng còn khi các nhà cung cấp danh tính như AD hoặc những nhà cung cấp khác không có thuộc tính bổ sung đã được sử dụng trong các dự án khác nhau thì sao. Một loại hệ thống được gọi là "nhà môi giới nhận dạng" sẽ ra tay giải cứu. Chức năng nhất là các đại diện của nó, chẳng hạn như Keycloak, quản lý Gravitee Access, v.v. Thông thường, các trường hợp sử dụng có thể khác nhau: tương tác máy, sự tham gia của người dùng, v.v. Giải pháp phải hỗ trợ chức năng linh hoạt và có thể mở rộng để có thể kết hợp tất cả các yêu cầu trong một, và những giải pháp như vậy, công ty chúng tôi hiện có một nhà môi giới chỉ dẫn - Keycloak.
Keycloak là một sản phẩm kiểm soát truy cập và nhận dạng nguồn mở được duy trì bởi RedHat. Là cơ sở cho các sản phẩm của công ty sử dụng SSO – RH-SSO.
Khái niệm cơ bản
Trước khi bắt đầu giải quyết các giải pháp và cách tiếp cận, bạn nên quyết định về các điều khoản và trình tự của các quy trình:
Nhận dạng là một thủ tục nhận dạng một chủ thể bằng mã định danh của anh ta (nói cách khác, đây là định nghĩa về tên, thông tin đăng nhập hoặc số).
Xác thực - đây là quy trình xác thực (người dùng được kiểm tra bằng mật khẩu, thư được kiểm tra bằng chữ ký điện tử, v.v.)
Ủy quyền – đang cung cấp quyền truy cập vào một tài nguyên (ví dụ: email).
Nhà môi giới nhận dạng Keycloak
Móc khóa là một giải pháp quản lý quyền truy cập và nhận dạng nguồn mở được thiết kế để sử dụng trong IS nơi có thể sử dụng các mẫu kiến trúc vi dịch vụ.
Keycloak cung cấp các tính năng như đăng nhập một lần (SSO), nhận dạng được môi giới và đăng nhập xã hội, liên kết người dùng, bộ điều hợp máy khách, bảng điều khiển dành cho quản trị viên và bảng điều khiển quản lý tài khoản.
Chức năng cơ bản được Keycloak hỗ trợ:
- Đăng nhập một lần và Đăng xuất một lần cho các ứng dụng trình duyệt.
- Hỗ trợ OpenID/OAuth 2.0/SAML.
- Môi giới nhận dạng – xác thực bằng cách sử dụng các nhà cung cấp nhận dạng OpenID Connect hoặc SAML bên ngoài.
- Đăng nhập xã hội - Hỗ trợ Google, GitHub, Facebook, Twitter để nhận dạng người dùng.
- Liên kết người dùng - đồng bộ hóa người dùng từ máy chủ LDAP và Active Directory cũng như các nhà cung cấp danh tính khác.
- Cầu Kerberos - sử dụng máy chủ Kerberos để xác thực người dùng tự động.
- Bảng điều khiển dành cho quản trị viên - để quản lý thống nhất các cài đặt và thông số giải pháp qua Web.
- Bảng điều khiển quản lý tài khoản – để quản lý hồ sơ người dùng độc lập.
- Tùy chỉnh giải pháp dựa trên bản sắc công ty của công ty.
- Xác thực 2FA - Hỗ trợ TOTP/HOTP bằng Google Authenticator hoặc FreeOTP.
- Luồng đăng nhập – người dùng có thể tự đăng ký, khôi phục và đặt lại mật khẩu, v.v.
- Quản lý phiên - quản trị viên có thể quản lý phiên của người dùng từ một điểm duy nhất.
- Trình ánh xạ mã thông báo - ràng buộc các thuộc tính, vai trò của người dùng và các thuộc tính bắt buộc khác với mã thông báo.
- Quản lý chính sách linh hoạt trên toàn lĩnh vực, ứng dụng và người dùng.
- Hỗ trợ CORS - Bộ điều hợp máy khách có hỗ trợ CORS tích hợp.
- Giao diện nhà cung cấp dịch vụ (SPI) – một số lượng lớn SPI cho phép bạn định cấu hình các khía cạnh khác nhau của máy chủ: luồng xác thực, nhà cung cấp danh tính, ánh xạ giao thức và hơn thế nữa.
- Bộ điều hợp máy khách cho các ứng dụng JavaScript, WildFly, JBoss EAP, Fuse, Tomcat, Jetty, Spring.
- Hỗ trợ làm việc với nhiều ứng dụng hỗ trợ thư viện OpenID Connect Relying Party hoặc Thư viện nhà cung cấp dịch vụ SAML 2.0.
- Có thể mở rộng bằng cách sử dụng plugin.
Đối với các quy trình CI/CD, cũng như tự động hóa các quy trình quản lý trong Keycloak, có thể sử dụng REST API/JAVA API. Tài liệu có sẵn dưới dạng điện tử:
REST API
API JAVA
Nhà cung cấp nhận dạng doanh nghiệp (tại chỗ)
Khả năng xác thực người dùng thông qua các dịch vụ Liên kết người dùng.
Xác thực chuyển tiếp cũng có thể được sử dụng - nếu người dùng được xác thực trên máy trạm bằng Kerberos (LDAP hoặc AD), thì họ có thể được xác thực tự động với Keycloak mà không cần phải cung cấp lại tên người dùng và mật khẩu.
Để xác thực và ủy quyền thêm cho người dùng, có thể sử dụng DBMS quan hệ, phù hợp nhất cho môi trường phát triển vì nó không yêu cầu cài đặt và tích hợp dài dòng trong giai đoạn đầu của dự án. Theo mặc định, Keycloak sử dụng DBMS tích hợp để lưu trữ cài đặt và dữ liệu người dùng.
Danh sách các DBMS được hỗ trợ rất phong phú và bao gồm: MS SQL, Oracle, PostgreSQL, MariaDB, Oracle và các DBMS khác. Được thử nghiệm nhiều nhất cho đến nay là cụm Oracle 12C Release1 RAC và Galera 3.12 cho MariaDB 10.1.19.
Nhà cung cấp danh tính - đăng nhập xã hội
Có thể sử dụng thông tin đăng nhập từ mạng xã hội. Để kích hoạt khả năng xác thực người dùng, hãy sử dụng bảng điều khiển dành cho quản trị viên Keycloack. Không cần thay đổi mã ứng dụng và chức năng này có sẵn và có thể được kích hoạt ở bất kỳ giai đoạn nào của dự án.
Có thể sử dụng nhà cung cấp Nhận dạng OpenID/SAML để xác thực người dùng.
Các kịch bản ủy quyền điển hình sử dụng OAuth2 trong Keycloak
Luồng mã ủy quyền - được sử dụng với các ứng dụng phía máy chủ. Một trong những loại quyền ủy quyền phổ biến nhất vì nó rất phù hợp với các ứng dụng máy chủ nơi mã nguồn và dữ liệu máy khách của ứng dụng không được cung cấp cho người ngoài. Quá trình trong trường hợp này dựa trên sự chuyển hướng. Ứng dụng phải có khả năng tương tác với tác nhân người dùng (user-agent), chẳng hạn như trình duyệt web - để nhận mã ủy quyền API được chuyển hướng thông qua tác nhân người dùng.
dòng chảy ngầm - được sử dụng bởi các ứng dụng di động hoặc web (ứng dụng chạy trên thiết bị của người dùng).
Loại quyền ủy quyền ngầm được sử dụng bởi các ứng dụng web và di động nơi tính bảo mật của khách hàng không thể được đảm bảo. Loại quyền ngầm định cũng sử dụng chuyển hướng tác nhân người dùng, theo đó mã thông báo truy cập được chuyển đến tác nhân người dùng để sử dụng tiếp trong ứng dụng. Điều này làm cho mã thông báo có sẵn cho người dùng và các ứng dụng khác trên thiết bị của người dùng. Loại quyền ủy quyền này không xác thực danh tính của ứng dụng và bản thân quy trình này dựa trên URL chuyển hướng (đã đăng ký trước đó với dịch vụ).
Luồng tiềm ẩn không hỗ trợ mã thông báo làm mới mã thông báo truy cập.
Quy trình cấp chứng chỉ xác thực khách hàng — được sử dụng khi ứng dụng truy cập API. Loại quyền ủy quyền này thường được sử dụng cho các tương tác giữa máy chủ với máy chủ phải được thực hiện ở chế độ nền mà không có sự tương tác ngay lập tức của người dùng. Luồng cấp thông tin xác thực ứng dụng khách cho phép dịch vụ web (ứng dụng khách bí mật) sử dụng thông tin xác thực của chính nó thay vì mạo danh người dùng để xác thực khi gọi một dịch vụ web khác. Để có mức độ bảo mật cao hơn, dịch vụ gọi điện có thể sử dụng chứng chỉ (thay vì bí mật chung) làm thông tin xác thực.
Đặc tả OAuth2 được mô tả trong
Mã thông báo JWT và lợi ích của nó
JWT (JSON Web Token) là một tiêu chuẩn mở () xác định một cách nhỏ gọn và khép kín để truyền thông tin một cách an toàn giữa các bên dưới dạng đối tượng JSON.
Theo tiêu chuẩn, mã thông báo bao gồm ba phần ở định dạng cơ sở 64, được phân tách bằng dấu chấm. Phần đầu tiên được gọi là tiêu đề, chứa loại mã thông báo và tên của thuật toán băm để lấy chữ ký số. Phần thứ hai lưu trữ thông tin cơ bản (người dùng, thuộc tính, v.v.). Phần thứ ba là chữ ký số.
. .
Không bao giờ lưu trữ mã thông báo trong DB của bạn. Vì mã thông báo hợp lệ tương đương với mật khẩu nên việc lưu trữ mã thông báo cũng giống như lưu trữ mật khẩu ở dạng văn bản rõ ràng.
Truy cập thẻ là mã thông báo cấp cho chủ sở hữu quyền truy cập vào tài nguyên máy chủ an toàn. Nó thường có thời gian tồn tại ngắn và có thể mang thông tin bổ sung như địa chỉ IP của bên yêu cầu mã thông báo.
Làm mới mã thông báo là mã thông báo cho phép khách hàng yêu cầu mã thông báo truy cập mới sau khi hết thời gian sử dụng. Những token này thường được phát hành trong một thời gian dài.
Những ưu điểm chính của việc sử dụng trong kiến trúc microservice:
- Khả năng truy cập các ứng dụng và dịch vụ khác nhau thông qua xác thực một lần.
- Trong trường hợp không có một số thuộc tính bắt buộc trong hồ sơ người dùng, có thể làm phong phú chúng bằng dữ liệu có thể được thêm vào tải trọng, bao gồm cả tự động và nhanh chóng.
- Không cần lưu trữ thông tin về các phiên hoạt động, ứng dụng máy chủ chỉ cần xác minh chữ ký.
- Kiểm soát truy cập linh hoạt hơn thông qua các thuộc tính bổ sung trong tải trọng.
- Việc sử dụng chữ ký mã thông báo cho tiêu đề và tải trọng sẽ tăng tính bảo mật của giải pháp tổng thể.
Mã thông báo JWT - thành phần
Tiêu đề - theo mặc định, tiêu đề chỉ chứa loại mã thông báo và thuật toán được sử dụng để mã hóa.
Loại mã thông báo được lưu trữ trong khóa "typ". Phím 'loại' bị bỏ qua trong JWT. Nếu có khóa "typ" thì giá trị của nó phải là JWT để cho biết rằng đối tượng này là Mã thông báo Web JSON.
Khóa thứ hai "alg" xác định thuật toán được sử dụng để mã hóa mã thông báo. Nó nên được đặt thành HS256 theo mặc định. Tiêu đề được mã hóa trong base64.
{ "alg": "HS256", "type": "JWT"}
tải trọng (nội dung) - tải trọng lưu trữ mọi thông tin cần được kiểm tra. Mỗi khóa trong tải trọng được gọi là "yêu cầu". Ví dụ: bạn chỉ có thể vào ứng dụng theo lời mời (quảng cáo đã đóng). Khi chúng ta muốn mời ai đó tham gia, chúng ta sẽ gửi cho họ thư mời. Điều quan trọng là phải kiểm tra xem địa chỉ email có thuộc về người chấp nhận lời mời hay không, vì vậy chúng tôi sẽ đưa địa chỉ này vào tải trọng, vì điều này, chúng tôi lưu nó trong khóa "email"
{ "email": "[email được bảo vệ]"}
Các khóa trong tải trọng có thể tùy ý. Tuy nhiên, có một số dành riêng:
- iss (Nhà phát hành) - xác định ứng dụng mà mã thông báo được gửi.
- sub (Chủ đề) - xác định chủ đề của mã thông báo.
- aud (Đối tượng) là một mảng các chuỗi hoặc URI phân biệt chữ hoa chữ thường, là danh sách những người nhận mã thông báo này. Khi bên nhận nhận được JWT với khóa đã cho, nó phải kiểm tra sự hiện diện của chính nó ở bên nhận - nếu không thì bỏ qua mã thông báo.
- exp (Thời gian hết hạn) - Cho biết thời điểm token hết hạn. Tiêu chuẩn JWT yêu cầu tất cả quá trình triển khai của nó phải từ chối các mã thông báo đã hết hạn. Khóa exp phải là dấu thời gian ở định dạng unix.
- nbf (Không phải trước) là thời gian ở định dạng unix xác định thời điểm mã thông báo trở nên hợp lệ.
- iat (Issued At) - Khóa này biểu thị thời gian mã thông báo được phát hành và có thể được sử dụng để xác định tuổi của JWT. Khóa iat phải là dấu thời gian ở định dạng unix.
- Jti (JWT ID) — một chuỗi xác định mã định danh duy nhất của mã thông báo này, phân biệt chữ hoa chữ thường.
Điều quan trọng là phải hiểu rằng tải trọng không được truyền đi được mã hóa (mặc dù các mã thông báo có thể được lồng vào nhau và sau đó có thể truyền dữ liệu được mã hóa). Vì vậy, bạn không thể lưu trữ bất kỳ thông tin bí mật nào trong đó. Giống như tiêu đề, tải trọng được mã hóa base64.
Chữ ký - khi chúng ta có tiêu đề và tải trọng, chúng ta có thể tính toán chữ ký.
Mã hóa Base64: tiêu đề và tải trọng được lấy, chúng được kết hợp thành chuỗi thông qua dấu chấm. Sau đó, chuỗi này và khóa bí mật được đưa vào thuật toán mã hóa được chỉ định trong tiêu đề khóa ("alg"). Khóa có thể là bất kỳ chuỗi nào. Dây dài hơn sẽ được ưu tiên hơn vì sẽ mất nhiều thời gian hơn để lấy dây.
{"alg://RSA1_5","payload":A128CBC-HS256"}
Xây dựng kiến trúc cụm chuyển đổi dự phòng Keycloak
Khi sử dụng một cụm duy nhất cho tất cả các dự án, yêu cầu về giải pháp SSO sẽ tăng lên. Tuy nhiên, khi số lượng dự án ít, những yêu cầu này không quá đáng chú ý đối với tất cả các dự án, tuy nhiên, với sự gia tăng số lượng người dùng và khả năng tích hợp, các yêu cầu về tính khả dụng và hiệu suất cũng tăng lên.
Việc tăng rủi ro lỗi của một SSO đơn lẻ sẽ làm tăng các yêu cầu đối với kiến trúc giải pháp và các phương pháp được sử dụng để dự phòng các thành phần, đồng thời dẫn đến SLA rất nghiêm ngặt. Về vấn đề này, thường xuyên hơn trong quá trình phát triển hoặc giai đoạn đầu triển khai các giải pháp, các dự án đều có cơ sở hạ tầng không có khả năng chịu lỗi của riêng mình. Khi quá trình phát triển tiến triển, cần phải xây dựng các cơ hội để phát triển và mở rộng quy mô. Cách linh hoạt nhất để xây dựng cụm chuyển đổi dự phòng là sử dụng ảo hóa vùng chứa hoặc phương pháp kết hợp.
Để hoạt động ở chế độ cụm Chủ động/Chủ động và Chủ động/Thụ động, cần phải đảm bảo tính nhất quán của dữ liệu trong cơ sở dữ liệu quan hệ - cả hai nút cơ sở dữ liệu phải được sao chép đồng bộ giữa các trung tâm dữ liệu phân phối theo địa lý khác nhau.
Ví dụ đơn giản nhất về cài đặt có khả năng chịu lỗi.
Ưu điểm của việc sử dụng một cụm duy nhất là gì:
- Tính sẵn sàng và hiệu suất cao.
- Hỗ trợ các chế độ hoạt động: Active/Active, Active/Passive.
- Khả năng mở rộng quy mô linh hoạt - khi sử dụng ảo hóa vùng chứa.
- Khả năng quản lý và giám sát tập trung.
- Cách tiếp cận thống nhất để nhận dạng/xác thực/ủy quyền người dùng trong dự án.
- Tương tác minh bạch hơn giữa các dự án khác nhau mà không cần sự tương tác của người dùng.
- Khả năng sử dụng lại mã thông báo JWT trong các dự án khác nhau.
- Điểm tin cậy duy nhất.
- Khởi động nhanh hơn các dự án sử dụng vi dịch vụ/ảo hóa container (không cần cài đặt và định cấu hình các thành phần bổ sung).
- Có thể mua hỗ trợ thương mại từ nhà cung cấp.
Những điều cần chú ý khi lập kế hoạch cho một cụm
DBMS
Keycloak sử dụng hệ thống quản lý cơ sở dữ liệu để lưu trữ: các lĩnh vực, ứng dụng khách, người dùng, v.v.
Một loạt các DBMS được hỗ trợ: MS SQL, Oracle, MySQL, PostgreSQL. Keycloak đi kèm với cơ sở dữ liệu quan hệ tích hợp sẵn. Nên sử dụng cho các môi trường không tải - chẳng hạn như môi trường phát triển.
Để hoạt động ở các chế độ cụm Active/Active và Active/Passive, cần đảm bảo tính nhất quán của dữ liệu trong cơ sở dữ liệu quan hệ và cả hai nút của cụm cơ sở dữ liệu đều được sao chép đồng bộ giữa các trung tâm dữ liệu.
Bộ đệm phân tán (Infinspan)
Để cụm hoạt động chính xác, cần phải đồng bộ hóa bổ sung các loại bộ đệm sau bằng Lưới dữ liệu JBoss:
Phiên xác thực - được sử dụng để lưu dữ liệu khi xác thực một người dùng cụ thể. Các yêu cầu từ bộ đệm này thường chỉ bao gồm trình duyệt và máy chủ Keycloak chứ không phải ứng dụng.
Mã thông báo hành động được sử dụng cho các tình huống trong đó người dùng cần xác nhận hành động một cách không đồng bộ (qua email). Ví dụ: trong quá trình quên mật khẩu, bộ đệm Infinispan của actionTokens được sử dụng để theo dõi siêu dữ liệu về các mã thông báo hành động liên quan đã được sử dụng nên không thể sử dụng lại.
Bộ nhớ đệm và vô hiệu hóa dữ liệu liên tục - được sử dụng để lưu trữ dữ liệu liên tục vào bộ đệm để tránh các truy vấn không cần thiết đến cơ sở dữ liệu. Khi bất kỳ máy chủ Keycloak nào cập nhật dữ liệu, tất cả các máy chủ Keycloak khác trong tất cả các trung tâm dữ liệu đều cần biết về nó.
Công việc - Chỉ được sử dụng để gửi tin nhắn không hợp lệ giữa các nút cụm và trung tâm dữ liệu.
Phiên người dùng - được sử dụng để lưu trữ dữ liệu về phiên người dùng hợp lệ trong suốt thời gian phiên trình duyệt của người dùng. Bộ đệm phải xử lý các yêu cầu HTTP từ người dùng cuối và ứng dụng.
Bảo vệ lực lượng vũ phu - được sử dụng để theo dõi dữ liệu về các lần đăng nhập thất bại.
Cân bằng tải
Bộ cân bằng tải là điểm truy cập duy nhất vào keycloak và phải hỗ trợ các phiên cố định.
Máy chủ ứng dụng
Chúng được sử dụng để kiểm soát sự tương tác của các thành phần với nhau và có thể được ảo hóa hoặc chứa trong bộ chứa bằng các công cụ tự động hóa hiện có và khả năng mở rộng quy mô linh hoạt của các công cụ tự động hóa cơ sở hạ tầng. Các kịch bản triển khai phổ biến nhất trong OpenShift, Kubernates, Rancher.
Điều này kết thúc phần đầu tiên - phần lý thuyết. Trong loạt bài viết tiếp theo, chúng tôi sẽ phân tích các ví dụ về tích hợp với nhiều nhà cung cấp danh tính khác nhau và ví dụ về cài đặt.
Nguồn: www.habr.com