Trong dự án ký số, câu hỏi quản trọng không chỉ là "User này là ai" mà còn là "User này ở phòng ban nào, có quyền ký hay không". Để giải quyết vấn đề này thì LDAP/AD đã ra đời. Bài viết này sẽ giúp bạn hiểu rõ LDAP/AD và cách nó giải quyết vấn đề "Identity & Access Management" trong thực tế dự án.

LDAP - "Cuốn danh bạ" quyền lực của doanh nghiệp

Định Nghĩa

LDAP (Lightweight Directory Access Protocol) là giao thức chuẩn dùng để truy cập, tra cứu và xác thực thông tin trong thư mục tập trung (Directory Service). Có thể coi LDAP như là “Danh bạ trung tâm” lưu tài khoản, mật khẩu, phòng ban, chức vụ và cho phép hệ thống khác hỏi: “user này là ai, mật khẩu đúng không?”.

Tại sao cần dùng LDAP

Nếu không có LDAP, người dùng sẽ phải quản lý user thủ công. Rủi ro sẽ cực kì lớn khi một nhân viên đã nghỉ việc nhưng tài khoản trên hệ thống ký số vẫn hoạt động, từ đó có thể dẫn đến việc chữ ký bị giả mạo. LDAP sẽ giải quyết các vấn đề bao gồm :

• Xác thực (Authentication): Kiểm tra username/password đúng hay sai
• Tra cứu danh tính: Lấy thông tin user: phòng ban, chức vụ, email
• Quản lý tập trung user: Toàn công ty dùng 1 kho user duy nhất

Bảo mật kênh truyền: LDAPS vs StartTLS

LDAP "thô" chạy qua mạng có thể dễ để lộ các thông tin liên quan đến : user, password, dữ liệu về danh tính,... Vì vậy khi triển khai bắt buộc phải dùng TLS ( là giao thức bảo mật dùng để mã hóa dữ liệu khi truyền qua mạng) cho LDAP.

Keycloak & LDAP: Cơ chế User Federation

Keycloak không thể thay thế LDAP, nó chỉ là trung gian. Luồng xác thực:

1. User nhập form login trên Keycloak.
2. Keycloak sử dụng một Bind Account (tài khoản kỹ thuật) để tìm kiếm User trên LDAP
3. Keycloak thực hiện User Bind để xác thực password với LDAP.
4. Nếu LDAP trả về OK, Keycloak sinh ra JWT Token để ứng dụng Backend sử dụng.

Attribute Mapping - Chìa khóa cho phân quyền ký số (ABAC)

LDAP/AD lưu user theo “kiểu thư mục” (directory attributes), ví dụ:* cn, sn, givenName, mail, department, title, memberOf, …* Thế nhưng Keycloak lại dùng field chuẩn:* username, email, firstName, lastName...* , custom attributes: department, signlevel, employeecode, … và* groups/roles* để phân quyền. Để Backend ký số biết user thuộc Level nào, ta cần ánh xạ (mapping) thuộc tính từ LDAP sang JWT. Các tầng mapping :

• Tầng A (LDAP -> Keycloak): Ánh xạ department (LDAP) vào User Attribute của Keycloak.
• Tầng B (Keycloak -> JWT): Sử dụng Protocol Mapper để bơm thuộc tính đó vào Access Token.

Tầng A

Khi Keycloak “đọc” user từ LDAP, nó biết:

• field nào là username
• email ở attribute nào
• first/last name lấy từ đâu
• group LDAP nào tương ứng group/role nào

Tầng B

Đưa dữ liệu (đã có trong Keycloak) vào token:

• department
• title
• sign_level
• employee_code
• groups/roles…

Ví dụ

Một Claim trong JWT chuẩn cho ký số:

{
  "preferred_username": "ngocanh.dev",
  "department": "Kế toán",
  "sign_level": "LEVEL_2",
  "roles": ["SIGNER"]
}

Dựa vào đây, Backend có thể thực hiện chính sách: Chỉ ai có department=Kế toán và signlevel>=LEVEL2 mới được ký chứng từ này.

User Lifecycle & Sync: Khi nào thì "ngắt" quyền ký?

User Lifecycle

User lifecycle là toàn bộ các trạng thái và sự kiện mà một tài khoản trải qua từ lúc được tạo → được cấp quyền → thay đổi → bị khóa/thu hồi → nghỉ việc/xóa.

• Onboarding: Tạo user ở LDAP -> Keycloak tự nhận diện và cấp quyền ký.
• Change: Đổi phòng ban -> Thuộc tính trong Token thay đổi -> Quyền ký thay đổi theo.
• Offboarding (Nghỉ việc): Đây là trường hợp quan trọng nhất. Khi disable tài khoản ở LDAP, hệ thống phải chặn ký ngay lập tức.

Chiến lược Sync & Cache

Sync (đồng bộ) là cách Keycloak “cập nhật” thông tin user từ LDAP/AD và ngược lại .Để tối ưu, Keycloak thường cache thông tin user. Tuy nhiên, với hệ thống nhạy cảm như ký số:

• Access Token TTL: Nên để ngắn (1-5 phút).
• Sync Trạng thái: Đảm bảo khi LDAP disable, Keycloak cũng phải thu hồi session của user đó.

Các mô hình sync phổ biến

1. Mô hình A — Federation “Read-only”

• User nằm trong LDAP/AD
• Keycloak chỉ dùng để login + cấp token
• Keycloak không “quản” password
• Thay đổi password, disable… làm trong LDAP

Rất phù hợp cho doanh nghiệp đã có AD, quyền sống/chết của user theo LDAP giúp chặt chẽ về vấn đề pháp lý

2. Mô hình B — Import user (copy user vào Keycloak)

• Lần đầu user login → Keycloak import user vào DB của nó
• Một số thuộc tính có thể “đóng băng” (tùy config)
• LDAP có thể vẫn dùng để xác thực, hoặc chỉ dùng ban đầu

Giảm phụ thuộc LDAP (nếu LDAP chập chờn)

3. Mô hình C — Hybrid: LDAP cho AuthN, Keycloak cho AuthZ

• LDAP xác thực: user/pass đúng không
• Keycloak quản lý role/permission/sign-level theo policy riêng
• Các thông tin tổ chức (department/title) lấy từ LDAP, role ký do Keycloak cấp

Những điều cần lưu ý khi triển khai thực tế cho dự án Ký số

1. Bảo mật: Luôn dùng LDAPS (636) hoặc StartTLS.
2. Bind Account: Sử dụng tài khoản kỹ thuật có quyền "Least Privilege" (chỉ đọc).
3. Username Mapping: Xác định đúng uid (OpenLDAP) hoặc sAMAccountName (AD).
4. Mapping chuẩn: Đưa các thông tin pháp lý (Mã nhân viên, Chức vụ) vào Token qua Protocol Mappers.
5. Token Lifetime: Cấu hình thời gian sống của Token phù hợp để cân bằng giữa bảo mật và hiệu năng.