CloudFoundry UAA Server: máy chủ OAuth2 định danh

Tìm hiểu về CloudFoundry UAA Server

CloudFoundry UAA Server là dịch vụ quản lý định danh đa tenant, ra đời bên trong Cloud Foundry nhưng cũng chạy độc lập như một máy chủ OAuth2. Đây là một ứng dụng web Spring MVC thuần túy, không cần runtime độc quyền, cấp token OAuth2, xác thực người dùng bằng thông tin đăng nhập Cloud Foundry hoặc nguồn khác, và đóng vai trò dịch vụ đăng nhập một lần (SSO). Nó còn cung cấp các endpoint để quản lý tài khoản người dùng và đăng ký client OAuth2.

Tính năng định danh và truy cập cốt lõi

• ✓Máy chủ OAuth2 — triển khai các endpoint /oauth/authorize và /oauth/token theo tài liệu UAA-APIs, cấp token để các ứng dụng client dùng thay mặt người dùng Cloud Foundry.
• ✓Hỗ trợ OpenID Connect một phần — cung cấp các endpoint OpenID Connect như /userinfo, nhưng README nói rõ đây chỉ là hỗ trợ một phần chứ không tuân thủ đầy đủ chuẩn OIDC.
• ✓Endpoint cấp phát người dùng theo chuẩn SCIM, cùng các endpoint để đăng ký client OAuth2.
• ✓Kiểm tra token qua /check_token để resource server xác minh token do client OAuth2 gửi lên, và /token_key để lấy khóa xác minh chữ ký token.
• ✓Endpoint /login_info cho phép client truy vấn những bước đăng nhập nào là bắt buộc trước khi xác thực.
• ✓Thiết kế đa tenant theo identity zone — bảng schema Postgres trong README có bảng identity_zone bên cạnh oauth_client_details, groups và group_membership, phản ánh đúng kiến trúc đa tenant.
• ✓Tích hợp LDAP được tài liệu hóa riêng, cho phép UAA xác thực qua thư mục LDAP bên ngoài, được kiểm thử trong chính hướng dẫn của README bằng container OpenLDAP của Bitnami.
• ✓SSO tích hợp sẵn — sau khi xác thực, UAA có thể đóng vai trò dịch vụ đăng nhập một lần cho các ứng dụng khác dùng chung thông tin đăng nhập.

Các luồng xác thực điển hình

• •Đăng nhập trực tiếp — GET /login hiển thị một form đăng nhập HTML cơ bản.
• •Cấp quyền cho ứng dụng client — GET /oauth/authorize?client_id=...&response_type=code chạy luồng authorization code chuẩn của OAuth2 để ứng dụng bên thứ ba xin quyền thay mặt người dùng.
• •Đổi mã lấy token — POST /oauth/token hoàn tất luồng trên và trả token truy cập cho client.
• •Xác thực từ dòng lệnh — client dòng lệnh có thể gửi thông tin đăng nhập trực tiếp tới /oauth/authorize, còn client Java có thể dùng ImplicitAccessTokenProvider của Spring Security OAuth để xử lý luồng này.
• •Làm lớp xác thực cho Cloud Foundry — cấp token để các dịch vụ backend và ứng dụng dùng khi thực hiện hành động thay mặt người dùng Cloud Foundry.

Khởi động nhanh và các cách deploy

Clone repo rồi chạy `./gradlew run` (hoặc `./gradlew bootRun`) từ thư mục `uaa` — README ghi thẳng: nếu lệnh này chạy được là bạn đã sẵn sàng. Yêu cầu: Java 25. Khi chạy qua Gradle, ứng dụng lắng nghe ở cổng 8080, truy cập tại http://localhost:8080/uaa (cùng /app và /api trên cùng cổng đó). Log được ghi vào file uaa.log; README gợi ý tìm file này bằng `sudo lsof | grep uaa.log`, thường nằm dưới scripts/boot/tomcat/logs/. Kiểm tra server đã chạy bằng `curl --silent --show-error --head localhost:8080/uaa/login | head -1`, kết quả mong đợi là HTTP/1.1 200. Nếu dùng cho việc gì nghiêm túc hơn một bản demo, nên deploy file WAR đã build vào Tomcat hoặc container khác thay vì chạy qua Gradle. Có ba task Gradle cho các chế độ chạy khác nhau — `./gradlew run` (tắt UAA đang chạy rồi khởi động lại, được khuyến nghị), `./gradlew bootRun` (task Spring Boot chuẩn), và `./gradlew bootWarRun` (chạy file .war đã đóng gói). Mặc định server chạy với HSQLDB; muốn chuyển sang MySQL hoặc PostgreSQL thì cần tự khởi động database riêng (README có ví dụ Docker) và truyền `-Dspring.profiles.active=mysql` hoặc `=postgresql`.

Các lựa chọn thay thế trong quản lý định danh

Câu hỏi thường gặp

Vấn đề mà nó giải quyết

Cloud Foundry cần một dịch vụ duy nhất có thể cấp token OAuth2, xác thực người dùng bằng thông tin đăng nhập Cloud Foundry, đồng thời quản lý cả tài khoản người dùng lẫn client OAuth2 đã đăng ký — để không thành phần nào trong nền tảng phải tự viết lại logic đăng nhập và cấp token riêng. CloudFoundry UAA Server chính là mảnh ghép đó: lớp định danh và cấp token mà phần còn lại của nền tảng Cloud Foundry, và cả ứng dụng của bạn nếu muốn, gọi tới thay vì tự xây dựng cơ chế xác thực từ đầu.

Nên dùng khi nào — và khi nào nên bỏ qua

Hãy thử CloudFoundry UAA Server nếu bạn đang vận hành Cloud Foundry hoặc một nền tảng deploy qua BOSH và cần đúng thành phần định danh tương thích, hoặc nếu bạn muốn một máy chủ OAuth2 tự triển khai trên nền Spring có sẵn cấp phát người dùng theo SCIM và không ngại vận hành stack Java/Tomcat/Gradle. Bỏ qua nó nếu bạn cần tuân thủ đầy đủ chuẩn OpenID Connect ngay bây giờ — README ghi rõ phần hỗ trợ OIDC chỉ ở mức một phần — hoặc thấy việc duy trì một dịch vụ JVM chỉ để xử lý đăng nhập và token cho một ứng dụng nhỏ là quá mức cần thiết; một nhà cung cấp định danh nhẹ hơn hoặc tuân thủ OIDC đầy đủ hơn sẽ phù hợp hơn trong trường hợp đó.

Repo liên quan