Liên hệ | RSS | VI → EN
CloudflareCloudflare OneIdentityOktaEntra ID

Integrate IdP: Okta, Entra ID, Google Workspace, SAML generic

Ma trận 4 IdP phổ biến với Cloudflare Access: OIDC vs SAML, cạm bẫy group claim, claim mapping, group sync timing, pattern multi-IdP, checklist trước production.

· 17 phút đọc · Read in English
  • KhaVan AWS APJ Community Leader 2024 · Co-founder Viet-AWS
Ma trận tích hợp IdP cho Cloudflare Access: OIDC vs SAML cho Okta, Entra ID, Google Workspace và SAML generic, kèm cạm bẫy group claim theo từng IdP, claim mapping và pattern multi-IdP

TL;DR

Cloudflare Access không tự quản mật khẩu, nó tin IdP (identity provider) để xác thực. 90% sự cố chính sách “hoạt động sai” mình từng truy nguyên không phải ở Cloudflare, mà ở cách IdP trả claims, đặc biệt là group claims.

Bài này đi ma trận 4 IdP phổ biến (Okta, Entra ID, Google Workspace, SAML generic), chỉ rõ:

  • OIDC vs SAML: khi nào chọn cái nào.
  • Định dạng group claim khác nhau thế nào giữa 4 IdP.
  • 3 cạm bẫy lớn: Entra ID trả group object ID thay vì tên, Google cần service account + Admin SDK, SAML generic cần ánh xạ thuộc tính chính xác.
  • Thời điểm đồng bộ group: khoảng trống giữa lúc admin xóa người dùng và lúc Cloudflare biết.
  • Mẫu nhiều IdP cho nhân viên + nhân sự thuê ngoài.

Luận điểm chính:

Tích hợp IdP không phải “bấm next 5 lần”. Chất lượng group claim quyết định chất lượng mọi chính sách viết sau này. Đầu tư 1 ngày thiết lập đúng IdP tiết kiệm 3 tháng truy nguyên chính sách.

Bài này là Part 5 của Cloudflare One Handbook.

Dành cho ai

  • Kỹ sư bảo mật/nền tảng thiết lập Cloudflare Access + IdP lần đầu.
  • Kỹ sư IAM muốn hiểu cách Cloudflare tiêu thụ claims từ IdP.
  • Người đang kẹt ở bug “chính sách khớp group không chạy”.

Bạn nên đã đọc:

Sau bài này bạn sẽ:

  • Biết chọn OIDC hay SAML.
  • Có hướng dẫn từng bước cho 4 IdP phổ biến.
  • Hiểu cách ánh xạ claim → rule hoạt động (và fail).
  • Biết trễ đồng bộ group có rủi ro gì, giảm thiểu thế nào.
  • Có danh sách kiểm tra rà soát tích hợp IdP trước đưa vào production.

Bài này không nói về gì

  • SCIM provisioning đào sâu: Part 7 (bài kế tiếp).
  • Service tokens + mTLS cho non-human: Part 6.
  • Okta Workflows / Entra Conditional Access riêng biệt là chủ đề nâng cao, ngoài phạm vi Cloudflare.
  • Passkey / passwordless: đang phát triển, khuyến nghị kiểm tra tài liệu gần nhất.

Khái niệm

  • IdP (Identity provider): máy chủ xác thực người dùng và cấp token. Ví dụ: Okta, Entra ID, Google Workspace, Auth0.
  • OIDC (OpenID Connect): giao thức hiện đại cho SSO, dựa trên OAuth 2.0. Token = JWT.
  • SAML 2.0: giao thức legacy doanh nghiệp, token = XML đã ký.
  • Claims: thuộc tính key-value về người dùng (email, groups, department) mà IdP trả về CF.
  • Phạm vi (chỉ OIDC): quyền CF xin từ IdP. Ví dụ openid profile email groups.
  • Attribute statement (chỉ SAML): tương đương claims nhưng trong XML.
  • IdP connector: đối tượng cấu hình trong dashboard Cloudflare ánh xạ tới IdP thật.
  • SCIM: giao thức đẩy cập nhật user/group từ IdP sang Cloudflare thời gian thực.

OIDC vs SAML: chọn cái nào?

OIDC 5-step vs SAML 5-step, cùng concept, khác transport

OIDC (khuyến nghị mặc định)

Khi dùng: IdP hiện đại (Okta, Entra ID, Google, Auth0, Keycloak). Hầu hết IdP phổ biến 2020+ đều hỗ trợ OIDC.

Ưu:

  • Vận chuyển qua JSON: truy nguyên dễ hơn XML.
  • Token là JWT: có thể decode bằng jwt.io khi truy nguyên.
  • Phạm vi chi tiết: yêu cầu đúng thứ cần (email, groups), không nhiều hơn.
  • Thiết lập đơn giản hơn: không cần tải lên chứng chỉ.

Nhược:

  • Trao đổi token qua HTTPS backend: IdP phải tới được từ Cloudflare edge (thường OK).

SAML 2.0

Khi dùng:

  • IdP chỉ hỗ trợ SAML (một số IdP doanh nghiệp cũ như Shibboleth, OpenAM).
  • Tổ chức có chuẩn nội bộ “tất cả phải SAML” vì tuân thủ.
  • Cần tương thích federation với đối tác đã thiết lập SAML.

Ưu:

  • Không cần trao đổi token backend: SAMLResponse đi trong HTTP redirect qua trình duyệt.
  • IdP doanh nghiệp trưởng thành hỗ trợ.

Nhược:

  • Truy nguyên xác minh chữ ký XML phức tạp.
  • Cần tải lên/quản lý chứng chỉ ký của IdP, xoay khi hết hạn.
  • Ánh xạ thuộc tính cần chính xác, dễ typo.

Khuyến nghị

Nếu IdP của bạn hỗ trợ cả hai, chọn OIDC. SAML chỉ dùng khi bắt buộc.

Ma trận IdP: 4 lựa chọn phổ biến

Bảng so sánh Okta, Entra ID, Google Workspace, SAML generic theo protocol, group claim, SCIM, gotcha chính

Xem chi tiết từng IdP ở các section dưới.

Thiết lập 1: Okta (OIDC)

Bước 1: Tạo OIDC app trong Okta

Okta admin console → Applications → Create App Integration → OIDC - OpenID Connect → Web Application.

  • Name: Cloudflare Access
  • Grant type: Authorization Code
  • Sign-in redirect URIs: https://<team>.cloudflareaccess.com/cdn-cgi/access/callback
    • Thay <team> bằng team name của bạn (dashboard Zero Trust → Settings → General → Team domain).
  • Sign-out redirect URIs: https://<team>.cloudflareaccess.com
  • Controlled access: chọn assignment (Allow everyone, hoặc specific groups).

Lưu → copy Client ID và Client Secret xuất hiện.

Bước 2: Cấu hình groups claim

Đây là chỗ hầu hết thiết lập Okta sai. Mặc định Okta không gồm groups trong token, bạn phải bật rõ ràng.

Trong Okta app vừa tạo → tab Sign On → OpenID Connect ID Token → Edit:

  • Groups claim type: Filter (khuyến nghị) hoặc Expression.
  • Groups claim filter:
    • Filter name: groups
    • Filter: Matches regex → .*
    • Hoặc tách theo tiền tố: starts with → cf- (chỉ đồng bộ group tên bắt đầu bằng cf-).

Khuyến nghị: dùng tiền tố để giới hạn phạm vi. Nếu Okta có 500 groups và bạn filter .*, token sẽ lớn (có thể > 8KB) và chậm.

Bước 3: Cấu hình trong Cloudflare

Zero Trust → Settings → Authentication → Login methods → Add new → Okta.

  • Name: Okta Corporate
  • App ID (Client ID): từ Okta
  • Client Secret: từ Okta
  • Okta account URL: https://<yourcompany>.okta.com (không có /oauth2/...)

Lưu → Test (Cloudflare sẽ redirect trình duyệt qua Okta + về → nếu xanh là OK).

Bước 4: Ánh xạ vào Access Application

Tạo/chỉnh sửa Access application → chọn Okta Corporate trong Identity providers → lưu.

Cạm bẫy Okta thường gặp

  • Claim “groups” trống → người dùng không nằm trong Groups claim filter ở Okta. Kiểm tra Okta → Directory → Groups → người dùng có là thành viên không.
  • Token quá lớn (lỗi 413) → groups filter quá rộng, lọc về tiền tố hẹp hơn.
  • “Admin consent required” → người dùng không trong Assignment của app. Thêm user/group vào Assignment.
  • Lệch đồng hồ → IdP và Cloudflare timestamp lệch, JWT không hợp lệ. Cực hiếm, nhưng nếu gặp, kiểm tra NTP.

Thiết lập 2: Microsoft Entra ID (OIDC)

Entra ID (Azure AD cũ) có thể tích hợp qua OIDC hoặc SAML. OIDC khuyến nghị.

Bước 1: Tạo App Registration

Azure portal → Microsoft Entra ID → App registrations → New registration.

  • Name: Cloudflare Access
  • Loại tài khoản hỗ trợ: Single tenant (hoặc multi-tenant nếu cần federation).
  • Redirect URI: Web → https://<team>.cloudflareaccess.com/cdn-cgi/access/callback

Đăng ký → copy Application (client) ID và Directory (tenant) ID.

Bước 2: Tạo client secret

App registration → Certificates & secrets → New client secret. Đặt hạn 24 tháng (hoặc ngắn hơn).

Copy Value (không phải Secret ID), hiện 1 lần duy nhất.

Bước 3: Cấu hình group claim

Đây là phần khác biệt lớn nhất với Okta: Entra ID mặc định trả group object ID, không phải tên.

App registration → Token configuration → Add groups claim.

  • Which groups: Security groups (hoặc All groups tùy nhu cầu).
  • Customize: trong ID token, chọn Group ID (mặc định) HOẶC sAMAccountName nếu tổ chức đồng bộ từ on-prem AD.

Cạm bẫy lớn: nếu bạn chọn Group ID (giá trị mặc định), token sẽ trả về GUID như 00000000-0000-0000-0000-abc123.... Rule Cloudflare phải viết theo GUID, không phải tên group.

Giải pháp:

  • Phương án A (khuyến nghị): Dùng SCIM provisioning (Part 7). SCIM đẩy tên group thật sang Cloudflare, chính sách viết theo tên.
  • Phương án B: Dùng sAMAccountName nếu tổ chức đồng bộ từ AD: có tên thật trong claim.
  • Phương án C: Viết chính sách theo GUID (không khuyến nghị: khó đọc, khó kiểm toán).

Bước 4: Permissions + admin consent

App registration → API permissions → Add a permission:

  • Microsoft Graph → Delegated permissions → openid, profile, email.
  • Nếu muốn groups: thêm GroupMember.Read.All (application permission): cần đồng ý của admin.

Click Grant admin consent for .

Bước 5: Cấu hình trong Cloudflare

Zero Trust → Settings → Authentication → Add new → Azure AD (Cloudflare vẫn giữ tên cũ trong UI).

  • Application (client) ID: Client ID từ Entra
  • Client Secret: Value từ bước 2
  • Azure Cloud: Public (hoặc phù hợp với tenant bạn)
  • Directory ID: Tenant ID

Lưu → Test.

Cạm bẫy Entra ID thường gặp

  • Group claim trả GUID, rule viết theo tên → khớp fail. Xem cạm bẫy ở trên.
  • “Groups overage claim”: Entra có giới hạn cứng: nếu người dùng là thành viên > 150 groups (với SAML) hoặc > 200 groups (với JWT), token chỉ trả link chứ không liệt kê group. Cloudflare không phân giải link này được. Giảm thiểu: SCIM, hoặc giới hạn số group mỗi user.
  • Client secret hết hạn: xoay ngầm. Chính sách hoạt động rồi một ngày đổ. Đặt nhắc lịch.
  • Tenant ID nhầm subscription ID: khi copy từ portal dễ nhầm. Tenant ID là GUID trong Microsoft Entra ID → Overview, không phải trong Subscriptions.

Thiết lập 3: Google Workspace (OIDC)

Google dễ thiết lập cơ bản, khó khi cần groups.

Bước 1: Tạo OAuth 2.0 Client ID

Google Cloud Console → dự án mới (hoặc hiện có) → APIs & Services → Credentials → Create Credentials → OAuth client ID.

  • Application type: Web application
  • Authorized redirect URIs: https://<team>.cloudflareaccess.com/cdn-cgi/access/callback

Lưu → copy Client ID và Client secret.

APIs & Services → OAuth consent screen → cấu hình:

  • User type: Internal (nếu chỉ cho tenant Workspace của bạn).
  • Phạm vi: openid, profile, email.

Bước 3: Cấu hình trong Cloudflare

Zero Trust → Settings → Authentication → Add new → Google Workspace.

  • Client ID, Client Secret: từ GCP.
  • Google Workspace Domain: example.com (tenant của bạn).

Lưu → Test.

Bước 4: Bật groups (phức tạp)

Google không trả groups trong OIDC ID token mặc định. Để Cloudflare đọc được groups:

  1. GCP Console → IAM & Admin → Service Accounts → Create Service Account.
  2. Đặt tên, tạo.
  3. Grant domain-wide delegation: bật trong chi tiết service account.
  4. Tạo key (JSON), tải về.
  5. Google Workspace Admin Console → Security → API controls → Domain-wide Delegation → Add new:
    • Client ID: ID số của service account.
    • Phạm vi OAuth: https://www.googleapis.com/auth/admin.directory.group.readonly
  6. Cloudflare → cấu hình Google IdP → bật groups → dán JSON key của service account.

Đây là lý do Google khó hơn Okta/Entra: cần Admin SDK + service account + domain-wide delegation. Nếu bạn không có quyền admin Google Workspace, bỏ qua groups, chính sách chỉ viết theo email.

Cạm bẫy Google Workspace thường gặp

  • Groups không hiện → chưa thiết lập service account + Admin SDK. Chính sách viết theo groups fail.
  • “User not a member of any Google Group” → người dùng ở Workspace OU nhưng không trong bất kỳ group nào. Tạo group hoặc dựa vào chính sách theo email.
  • Rò rỉ key service account → cấp quyền mạnh. Xoay định kỳ, lưu ở secret manager.

Thiết lập 4: SAML generic

Dùng khi IdP của bạn không có tích hợp sẵn (Shibboleth, ADFS, Keycloak, JumpCloud, PingOne, v.v.).

Bước 1: Cấu hình IdP

Trên phía IdP, tạo SAML application với:

  • Entity ID / Audience: https://<team>.cloudflareaccess.com/cdn-cgi/access/callback
  • ACS URL / Reply URL: https://<team>.cloudflareaccess.com/cdn-cgi/access/callback
  • Name ID format: EmailAddress
  • Thuật toán ký: SHA-256 (không SHA-1)
  • Want AuthnRequest signed: tùy chọn (Cloudflare hỗ trợ cả hai)
  • Thuộc tính:
    • email → email người dùng
    • groups hoặc memberOf → membership group (định dạng tùy IdP)

Tải xuống chứng chỉ ký của IdP (PEM hoặc X.509) và ghi SSO URL.

Bước 2: Cấu hình trong Cloudflare

Zero Trust → Settings → Authentication → Add new → SAML.

  • Name: ví dụ Corporate SAML
  • Single Sign On URL: SSO URL từ IdP
  • IdP Entity ID or Issuer URL: IdP entity ID
  • X509 Signing Certificate: dán cert PEM
  • Email attribute name: email (hoặc tên IdP dùng)
  • Thuộc tính: thêm groups nếu rule chính sách dùng

Lưu → Test.

Cạm bẫy SAML generic thường gặp

  • Typo tên thuộc tính → IdP gửi member-of, rule viết memberOf → không khớp. Phân biệt hoa/thường.
  • Chứng chỉ hết hạn → SAML assertion fail xác minh chữ ký. Giám sát hạn chứng chỉ (thường 1-3 năm).
  • Sai định dạng NameID → Cloudflare không trích xuất được email. Đổi sang EmailAddress.
  • Lệch đồng hồ → SAML assertion có NotBefore / NotOnOrAfter. Nếu đồng hồ IdP/CF lệch > 5 phút → từ chối. Đồng bộ NTP.

Giải phẫu claim mapping

Claim từ IdP JWT payload map sang Access policy rule qua 3 điểm align: key name, value type, giá trị cụ thể

3 điểm cần align

1. Tên key

Rule Cloudflare dùng groups. IdP có thể gửi:

  • Okta: groups (đúng, nếu cấu hình filter đúng tên)
  • Entra: groups (đúng) nhưng giá trị là GUID.
  • Google: groups (nếu service account + Admin SDK OK).
  • SAML: memberOf, group, roles, tùy IdP.

Nếu IdP gửi member-of nhưng rule tìm groups → khớp fail.

2. Kiểu giá trị (chuỗi vs mảng)

Groups thường là mảng chuỗi: ["Engineering", "Platform"].

Một số IdP trả chuỗi với dấu phân tách: "Engineering;Platform". Cloudflare không tự tách, rule sẽ khớp toàn bộ chuỗi “Engineering;Platform” như một group, không phải từng group.

Giảm thiểu: cấu hình IdP trả mảng, hoặc dùng SAML transformation để tách.

3. Giá trị cụ thể

  • Okta: "Engineering" (tên group)
  • Entra với chế độ Group ID: "00000000-..." (GUID)
  • Entra với sAMAccountName: "Engineering"
  • Google: email group@example.com hoặc tên tùy cấu hình
  • SAML: phụ thuộc IdP

Rule Cloudflare phải viết giá trị chính xác. Dashboard có tự hoàn thành cho user/group, nhưng chỉ hoạt động sau khi ít nhất 1 người dùng đăng nhập thành công và Cloudflare cache claim.

Cách xác minh ánh xạ claim

Trong dashboard Zero Trust → Logs → Access → click một sự kiện đăng nhập → tab Identity. Bạn thấy:

  • Email
  • Groups (nếu IdP trả)
  • Claims tuỳ chỉnh
  • Tên IdP

Nếu bạn viết rule groups: ["Engineering"] nhưng người dùng đăng nhập thành công lại không khớp, click sự kiện → kiểm tra tab Identity → xem IdP thực sự trả gì trong groups claim. 9/10 lần đây là nguyên nhân.

Group sync timing: cửa sổ stale

Câu hỏi quan trọng thường bị bỏ sót: admin xóa người dùng khỏi group ở IdP. Khi nào Cloudflare biết?

Dòng thời gian từ lúc admin gỡ user khỏi group: cửa sổ stale cho tới khi SCIM đồng bộ, session hết hạn, hoặc thu hồi cưỡng bức

Các cơ chế cập nhật claim

A. Claim tại thời điểm đăng nhập. Khi người dùng đăng nhập, IdP trả groups hiện tại. Nhưng claim đó được lưu trong JWT cookie CF_Authorization cho tới khi session hết hạn. Nếu thời lượng session = 24h, người dùng có thể có claim lỗi thời 24h sau khi admin gỡ.

B. SCIM provisioning. IdP đẩy cập nhật sang Cloudflare thời gian thực (< 5 phút) khi user/group thay đổi. Đây là cơ chế duy nhất “gần thời gian thực”, sẽ đi sâu ở Part 7.

C. Hết hạn session. Khi cookie hết hạn, người dùng bị bắt xác thực lại → claim mới từ IdP.

D. Thu hồi cưỡng bức. Admin → Zero Trust → Users → chọn user → Revoke. Vô hiệu hóa tất cả session.

Nguyên tắc thiết kế quanh cửa sổ stale

  • Thời lượng session ngắn cho app nhạy cảm: 15 phút tới 1 giờ. Đánh đổi ma sát UX.
  • Bật SCIM ngay từ đầu. Đây là giảm thiểu #1.
  • Quy trình thu hồi cưỡng bức: tài liệu hóa cho helpdesk. Khi người dùng thôi việc, không chỉ vô hiệu ở IdP mà còn thu hồi ở CF.
  • Rà soát định kỳ: truy vấn “users đã đăng nhập 30 ngày qua” và so sánh với danh sách user đang hoạt động của IdP. Chênh lệch = session lỗi thời chưa hết hạn.

Các pattern multi-IdP

Không phải tổ chức nào cũng có 1 IdP duy nhất. Vài pattern thường gặp:

Mẫu 1: Nhân viên + nhân sự thuê ngoài

  • Nhân viên: Okta Corporate (đầy đủ claims, SCIM bật).
  • Nhân sự thuê ngoài: One-time PIN (không cần IdP mới) hoặc GitHub/LinkedIn cho bên ngoài.
  • Cấu hình: Tạo 2 IdP connector. Theo từng ứng dụng, tick IdP nào được phép dùng.
  • Lợi ích: Nhân sự thuê ngoài không cần mời vào tenant Okta, không cần giấy phép.

Mẫu 2: Nhiều đơn vị kinh doanh, sáp nhập

  • Mỗi BU có Okta/Entra riêng.
  • Cấu hình: Tạo nhiều IdP connector, 1 cho mỗi BU. Ứng dụng cho BU nào tick IdP đó.
  • Cạm bẫy: Kiểm toán phức tạp hơn: log sự kiện phân mảnh giữa nhiều tenant.

Mẫu 3: Chính + dự phòng

  • Chính: Okta (bật mặc định cho tất cả app).
  • Dự phòng: One-time PIN bật cho 1 Access app “break-glass” để admin vẫn vào nếu Okta down.
  • Lợi ích: tránh bị đơn điểm hỏng ở IdP.

Đánh đổi

Quyết địnhPhương án APhương án BKhuyến nghị
Giao thứcOIDCSAMLOIDC nếu IdP hỗ trợ. SAML chỉ khi bắt buộc
Nguồn group claimClaim IdP tại đăng nhậpSCIM thời gian thựcCả hai. SCIM chính, claim dự phòng
Phạm vi filter groupsTất cả groupsLọc theo tiền tố (cf-*)Tiền tố, giảm kích thước token, kiểm toán dễ hơn
Nhiều IdP1 IdP cho tất cảChọn IdP theo từng appTheo app khi có nhân viên + nhân sự thuê ngoài riêng
Dự phòng One-time PINTắtBật cho break-glassBật cho ít nhất 1 Access app quản trị
Chế độ group EntraGroup ID (GUID)sAMAccountName / SCIMsAMAccountName nếu đồng bộ từ AD, SCIM cho cloud-native

Danh sách kiểm tra: rà soát tích hợp IdP trước production

Xác thực:

  • Client secret đã tài liệu hóa + lịch xoay.
  • Redirect URI khớp chính xác, không typo.
  • Kiểm thử kết nối thành công trong dashboard CF.
  • Ít nhất 2 admin có thể đăng nhập (không phụ thuộc một điểm duy nhất).

Claims:

  • Claim email trả đúng.
  • Claim groups trả đúng định dạng (mảng chuỗi với tên thật).
  • Nếu Entra ID: đã xác minh group claim không bị overage.
  • Claims tuỳ chỉnh (department, country) nếu chính sách dùng: xác minh trong log.

Đặt tên group:

  • Group IdP đã chuẩn hóa quy ước đặt tên (tiền tố, không có khoảng trắng, chữ thường hoặc PascalCase nhất quán).
  • Nếu dùng chế độ Group ID của Entra ID: đã tài liệu hóa ánh xạ GUID → tên.
  • Kiểm thử chính sách với 3 người dùng khác nhau (nhân viên, nhân sự thuê ngoài, admin).

Session + thu hồi:

  • Thời lượng session đặt phù hợp rủi ro (ngắn cho app nhạy cảm).
  • Quy trình thu hồi cưỡng bức đã tài liệu hóa cho helpdesk.
  • Kế hoạch tích hợp SCIM (Part 7): nếu chưa có, có lịch trình.

Nhiều IdP (nếu có):

  • Log kiểm toán tổng hợp: biết đăng nhập từ IdP nào.
  • IdP break-glass (One-time PIN) bật cho ít nhất 1 app quan trọng.

Bài học thực tế

  • Thiết lập IdP một lần, sống với nó 3 năm. Đừng cắt góc ở bước group claim: bug sẽ hiện 6 tháng sau khi đã có 50 chính sách dựa vào nó.
  • Ghi tài liệu quy ước đặt tên group ngay từ ngày 1. Tiền tố access- để phân biệt group dùng cho Cloudflare với group khác của tổ chức.
  • Overage claim của Entra ID là bug ma: chỉ hiện khi user là thành viên > 150 groups. Nhóm nhỏ không gặp. Nhóm doanh nghiệp gặp 6 tháng sau ra mắt.
  • Kiểm thử với “người dùng vừa vào, vừa nghỉ, đổi nhóm”: ba trường hợp vòng đời quan trọng nhất. Nếu không kiểm thử, bug lộ thật ở production.
  • Đừng bật mặc định cho tất cả người dùng trong Access application production. “Allow entire tenant” nghe hiền lành nhưng khi có nhân sự thuê ngoài tham gia tenant Okta để làm 1 việc khác, họ tự động có quyền truy cập mọi thứ.

Kết luận

IdP là phụ thuộc quan trọng nhất của Cloudflare Access. Cloudflare không thể “sửa” claim sai, nếu Okta gửi sai group, chính sách Cloudflare sẽ hành xử sai theo.

Đầu tư vào:

  1. Chọn giao thức đúng (OIDC trừ khi bắt buộc SAML).
  2. Cấu hình group claim chính xác với quy ước đặt tên rõ ràng.
  3. Kế hoạch SCIM ngay từ đầu, không đợi.
  4. Nhiều IdP khi có nhân sự thuê ngoài/người dùng ngoài tổ chức.
  5. Rà soát định kỳ, trôi dạt group, chứng chỉ hết hạn, vòng đời người dùng.

Nếu phải nhớ một câu:

Cloudflare Access chỉ mạnh bằng IdP tích hợp phía sau nó. Chất lượng claim từ IdP quyết định chất lượng mọi chính sách, không có đường tắt.

Trong Part 6 mình sẽ nói về Service tokens + mTLS, xác thực cho client không phải người dùng (CI/CD, bot, script), khi IdP không phù hợp.

Tài liệu tham khảo

Trong series này:

Bài liên quan