Tổng quan về SAML - Single Sign-On (SSO)

Một ví dụ điển hình trong doanh nghiệp: nhân viên đăng nhập một lần vào Microsoft Entra ID (hoặc Okta, ADFS) rồi mở các ứng dụng như Salesforce, Zoom, ServiceNow hay cổng quản trị FortiGate mà không phải nhập lại mật khẩu. Ở đây Entra ID đóng vai trò nhà cung cấp danh tính (IdP), còn mỗi ứng dụng là một nhà cung cấp dịch vụ (SP). Quản trị viên chỉ cần quản lý tài khoản, MFA và quyền truy cập tại một nơi.

Lưu ý: nút "đăng nhập bằng Google/Facebook" trên các website công cộng cũng là SSO nhưng thường chạy trên OAuth 2.0/OpenID Connect, không phải SAML (xem phần so sánh bên dưới).

Các thành phần chính trong SAML

Kiến trúc SAML 2.0: assertion, protocol, binding, profile

SAML 2.0 được tổ chức thành bốn lớp khái niệm, từ nội dung đến cách dùng:

• Assertion: phần nội dung bảo mật. Một assertion có thể chứa ba loại phát biểu: Authentication (người dùng đã xác thực bằng cách nào, lúc nào), Attribute (các thuộc tính của người dùng như email, nhóm, phòng ban) và Authorization decision (người dùng có được phép truy cập tài nguyên hay không).
• Protocol: các cặp yêu cầu/phản hồi, ví dụ AuthnRequest và Response (đăng nhập), LogoutRequest (đăng xuất), Artifact Resolution.
• Binding: cách ánh xạ thông điệp SAML lên giao thức truyền tải, phổ biến nhất là HTTP Redirect, HTTP POST, HTTP Artifact và SOAP.
• Profile: tổ hợp assertion, protocol và binding cho một tình huống cụ thể. Profile được dùng nhiều nhất là Web Browser SSO, ngoài ra còn Single Logout (SLO) và Enhanced Client or Proxy (ECP).

Trong luồng Web Browser SSO thông thường, AuthnRequest được gửi qua HTTP Redirect, còn phản hồi chứa assertion được gửi lại SP qua HTTP POST tới địa chỉ ACS.

Hai luồng đăng nhập: SP-initiated và IdP-initiated

Luồng 6 bước ở phần trên chính là SP-initiated. Trong thực tế, nhiều tổ chức dùng cả hai: IdP-initiated cho cổng ứng dụng nội bộ để người dùng bấm là vào, và SP-initiated cho các ứng dụng cần mức bảo mật cao hơn. Các biện pháp giảm rủi ro cho IdP-initiated (giới hạn thời gian hiệu lực assertion, kiểm tra audience, chống dùng lại assertion) chỉ làm giảm rủi ro chứ không đạt mức an toàn của SP-initiated, vì không khôi phục được cơ chế ràng buộc với yêu cầu ban đầu.

Assertion trông như thế nào?

Dưới đây là cấu trúc rút gọn của một assertion (giá trị minh họa):

<saml:Assertion Version="2.0" ID="_a1b2c3" IssueInstant="2026-10-28T03:00:00Z">
  <saml:Issuer>https://idp.example.com/metadata</saml:Issuer>
  <ds:Signature>...</ds:Signature>
  <saml:Subject>
    <saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">
      user@example.com
    </saml:NameID>
  </saml:Subject>
  <saml:Conditions NotBefore="2026-10-28T03:00:00Z" NotOnOrAfter="2026-10-28T03:05:00Z">
    <saml:AudienceRestriction>
      <saml:Audience>https://sp.example.com/metadata</saml:Audience>
    </saml:AudienceRestriction>
  </saml:Conditions>
  <saml:AuthnStatement AuthnInstant="2026-10-28T02:59:50Z"/>
  <saml:AttributeStatement>
    <saml:Attribute Name="groups">
      <saml:AttributeValue>Network-Admins</saml:AttributeValue>
    </saml:Attribute>
  </saml:AttributeStatement>
</saml:Assertion>

Các phần cần chú ý: Issuer (ai phát hành), Signature (chữ ký số), Subject/NameID (người dùng là ai), Conditions (khoảng thời gian hợp lệ và audience), AuthnStatement (đã xác thực khi nào) và AttributeStatement (thuộc tính như nhóm, vai trò).

So sánh SAML, OAuth 2.0 và OpenID Connect

Điểm cần nhớ: OAuth 2.0 không xác minh bạn là ai mà quản lý việc cấp quyền truy cập; SAML và OIDC mới là các chuẩn xác thực liên đoàn. Trong hệ thống doanh nghiệp, ba chuẩn này thường cùng tồn tại ở các lớp khác nhau: SAML cho SSO ứng dụng cũ, OAuth cho truy cập API, OIDC cho xác thực ứng dụng hiện đại.

Lưu ý bảo mật khi triển khai SAML

• Luôn kiểm tra chữ ký của assertion bằng chứng chỉ của IdP đã được cấu hình sẵn trên SP; không chấp nhận chứng chỉ lạ.
• Kiểm tra điều kiện: NotBefore/NotOnOrAfter còn hiệu lực, Audience đúng entity ID của SP, Destination trùng URL ACS.
• Giới hạn thời gian hiệu lực của assertion ở mức ngắn, đồng bộ thời gian (NTP) giữa IdP và SP để tránh lỗi lệch giờ.
• Theo dõi hạn chứng chỉ ký của IdP: chứng chỉ hết hạn hoặc được xoay vòng mà SP chưa cập nhật là nguyên nhân gây lỗi đăng nhập hàng loạt.
• Ưu tiên SP-initiated cho ứng dụng nhạy cảm; chỉ bật IdP-initiated khi thực sự cần.
• Bật MFA tại IdP: vì mọi ứng dụng tin cậy IdP, tài khoản IdP bị lộ đồng nghĩa mọi ứng dụng bị ảnh hưởng.
• Khớp thuộc tính: tên thuộc tính username/group mà IdP gửi phải khớp chính xác với cấu hình trên SP, nếu không việc ánh xạ người dùng và nhóm sẽ thất bại.

SAML SSO trên thiết bị Fortinet

SAML được tích hợp sẵn trên FortiGate cho nhiều tình huống:

• Đăng nhập quản trị FortiGate: SAML được đưa vào làm phương thức xác thực quản trị từ FortiOS 6.2. FortiGate đóng vai trò SP, IdP có thể là Microsoft Entra ID, Okta, JumpCloud, ADFS hoặc FortiAuthenticator. Khi cấu hình cần nhập IdP entity ID, IdP single sign-on URL, và nhập chứng chỉ ký của IdP vào FortiGate dưới dạng Remote Certificate.
• SSL VPN: FortiGate SSL VPN hỗ trợ SSO theo hướng SP-initiated. Người dùng được ánh xạ vào nhóm SAML trên FortiGate dựa trên thuộc tính username và group mà IdP trả về.
• Captive portal Wi-Fi, IPsec dial-up với FortiClient: cũng có thể dùng SAML với IdP như Entra ID.

Ngoài SAML, FortiGate còn có các cơ chế SSO khác dành cho người dùng nội bộ mạng LAN, không dựa trên trình duyệt như SAML. Bạn có thể tham khảo FortiGate Single Sign-On (FSSO) và bài lab RSSO trên FortiGate với 802.1X trên Cisco 2960.

Để tìm hiểu các giải pháp xác thực và bảo mật liên quan, xem thêm bài Giải pháp bảo mật FortiGate UTM và SASE là gì.

Khi nào nên dùng SAML SSO?

• Tổ chức có nhiều ứng dụng web/SaaS và muốn quản lý danh tính tập trung tại một IdP (AD, Entra ID, Okta).
• Cần áp dụng MFA và chính sách truy cập đồng nhất cho mọi ứng dụng, đồng thời thu hồi quyền nhanh khi nhân sự nghỉ việc.
• Cần giảm số lượng mật khẩu người dùng phải nhớ, giảm tải cho bộ phận hỗ trợ IT vì quên mật khẩu.
• Cần đăng nhập quản trị thiết bị mạng bằng tài khoản doanh nghiệp thay cho tài khoản cục bộ.

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

SAML SSO là gì? SAML SSO là cơ chế đăng nhập một lần dựa trên chuẩn SAML: người dùng xác thực tại nhà cung cấp danh tính (IdP), IdP gửi assertion XML đã ký cho ứng dụng (SP) để ứng dụng cho phép truy cập mà không cần nhập lại mật khẩu.

IdP và SP khác nhau thế nào? IdP là nơi lưu danh tính và xác thực người dùng, SP là ứng dụng hoặc thiết bị cung cấp dịch vụ và tin cậy IdP để quyết định cho truy cập.

SAML khác OAuth 2.0 ở điểm nào? SAML dùng để xác thực người dùng, còn OAuth 2.0 là khung ủy quyền cho phép ứng dụng truy cập tài nguyên thay mặt người dùng. OpenID Connect là lớp xác thực xây trên OAuth 2.0.

SP-initiated và IdP-initiated nên chọn loại nào? Ưu tiên SP-initiated vì có yêu cầu xác thực để đối chiếu với phản hồi, ít rủi ro hơn. IdP-initiated phù hợp cổng ứng dụng nội bộ tập trung nhưng cần thêm biện pháp giảm thiểu rủi ro.

Assertion SAML có mã hóa không? Assertion luôn cần được ký để SP xác minh nguồn gốc và tính toàn vẹn. Mã hóa assertion là tùy chọn bổ sung, thường dùng khi thông tin đi qua trình duyệt cần được giữ kín.

Vì sao đăng nhập SAML báo lỗi sau khi đổi chứng chỉ? Nguyên nhân thường gặp là chứng chỉ ký của IdP đã thay đổi nhưng SP vẫn giữ chứng chỉ cũ nên không xác thực được chữ ký. Cần nhập lại chứng chỉ mới của IdP vào SP.

FortiGate có hỗ trợ đăng nhập quản trị bằng SAML không? Có, từ FortiOS 6.2 FortiGate hỗ trợ SAML làm phương thức xác thực quản trị, với IdP như Entra ID, Okta, ADFS hoặc FortiAuthenticator.

Thông tin liên quan

• FortiGate Single Sign-On (FSSO)
• Lab RSSO trên FortiGate với 802.1X trên Cisco 2960
• Giải pháp bảo mật FortiGate UTM
• SASE là gì
• Cấu hình Guest WiFi với Cisco WLC và Cisco ISE

Nguồn tham khảo

• OASIS - SAML V2.0 Technical Overview
• Okta - OAuth, OpenID Connect và SAML khác nhau thế nào
• SecureW2 - IdP-initiated và SP-initiated SSO
• Fortinet Community - Cấu hình SAML SSO cho quản trị FortiGate với Entra ID
• Microsoft Learn - Tích hợp Entra SSO với FortiGate SSL VPN