- SAML (Single Assertion Markup Language) là một tiêu chuẩn định nghĩa các quy tắc để trao đổi những thông điệp liên quan đến bảo mật dưới dạng XML
- Chủ yếu được dùng để trao đổi thông điệp giữa từ 3 thực thể độc lập trở lên
- Kịch bản phổ biến là khi có hai hệ thống phần mềm do hai công ty khác nhau tạo ra cùng với người dùng liên quan
- Hai hệ thống cần trao đổi thông tin về người dùng
- Có thể làm integration tùy biến, nhưng sẽ khó bảo trì
- SAML đơn giản hóa các tác vụ tích hợp phức tạp bằng cách khiến các hệ thống tuân theo cùng một bộ quy tắc
Định dạng thông điệp SAML
- Thông điệp SAML được tạo thành ở định dạng XML
- Nó định nghĩa cú pháp của thông điệp và chỉ ra cách xử lý nội dung thông điệp một cách an toàn
- Ví dụ, khi nhận được thẻ
<Response> thì bạn sẽ biết cần tìm thẻ <Assertion>
- Nó cung cấp hướng dẫn về chữ ký số trông như thế nào và cách xử lý thông điệp để tránh các vấn đề bảo mật
Tính linh hoạt của SAML
- SAML được thiết kế với trọng tâm là tính linh hoạt. Về nguyên tắc, có thể làm rất nhiều việc với SAML, nhưng chính sự linh hoạt đó lại dẫn đến độ phức tạp
- Đặc tả SAML có rất nhiều ngoại lệ, nhiều điều kiện if và ví dụ, từ đó tạo ra thêm các edge case
- Vì SAML đã khá cũ nên một số người tận dụng tính linh hoạt đó
- Trong môi trường vận hành thực tế, đặc biệt là các hệ thống legacy, đôi khi SAML có hành vi bất thường
- Với đa số trường hợp, chỉ tập trung vào một tập con nhỏ của SAML sẽ khiến mọi thứ dễ chịu hơn nhiều
Mục đích sử dụng thực tế của SAML
- SAML chủ yếu được dùng cho Single Sign-On (SSO)
- SAML định nghĩa một vài kiểu SSO hơi lạ, nhưng thông thường người ta dùng Web Browser SSO Profile
- Người dùng cuối trước tiên xác thực với một hệ thống tập trung, sau đó truy cập ứng dụng phần mềm mà họ muốn dùng
- Người dùng không xác thực trực tiếp với ứng dụng
- Ví dụ, nếu bạn từng dùng Okta để truy cập email thì bạn đã sử dụng Web Browser SSO Profile
Các thực thể liên quan trong SSO
- Có 3 chủ thể tham gia trong SSO:
- Người dùng: người muốn sử dụng ứng dụng
- Nhà cung cấp dịch vụ (SP): bản thân ứng dụng
- Nhà cung cấp danh tính (IDP): dịch vụ trung tâm mà người dùng dùng để xác thực
- Có thể xem IDP của mỗi khách hàng như một cơ sở dữ liệu. Nó theo dõi dữ liệu về con người
- Các công ty thường dùng nhà cung cấp danh tính để phân nhân viên vào các phòng ban và cấp nhiều loại quyền khác nhau
- Mỗi khi đăng nhập người dùng qua SAML, cần lấy thông tin từ IDP. Trong SSO, chủ yếu là yêu cầu IDP xác nhận danh tính người dùng
- Cần có quan hệ tin cậy được cấu hình trước với IDP
- Mọi khách hàng dùng SAML SSO đều cần cấu hình riêng trong ứng dụng
- Tuy nhiên, không trực tiếp trao đổi thông điệp với IDP. Trong SAML SSO, nhà cung cấp dịch vụ và nhà cung cấp danh tính giao tiếp thông qua trình duyệt của người dùng
Cách các thực thể SAML tương tác với nhau
- Quy trình SAML SSO thông thường:
- Người dùng cố truy cập một phần nào đó của ứng dụng trong trình duyệt web
- Kiểm tra xem người dùng có security context hợp lệ hay không
- Người dùng không có security context hợp lệ, nên hiển thị trang đăng nhập
- Người dùng nhập một số thông tin (ví dụ: địa chỉ email), thông tin này được dùng để xác định phương thức đăng nhập phù hợp
- Chuyển hướng người dùng tới địa chỉ web của IDP và gửi thông điệp SAML tới IDP thông qua trình duyệt của người dùng
- IDP hiển thị lời nhắc yêu cầu thông tin xác thực cho người dùng. Người dùng được xác thực thành công
- IDP chuyển hướng người dùng quay lại ứng dụng cùng với một thông điệp SAML truyền tải thông tin về việc xác thực của người dùng
- Xử lý thông điệp SAML và xác định rằng cần thiết lập security context cho người dùng
- Cấp cho người dùng quyền truy cập vào phần mong muốn của ứng dụng
- Cũng có thể bắt đầu quy trình SAML SSO từ phía nhà cung cấp danh tính
- Trong trường hợp này, bạn sẽ nhận được phản hồi xác thực mà không gửi yêu cầu xác thực trước đó
- Khi triển khai hỗ trợ SAML SSO, cần chuẩn bị cho SSO do IDP khởi tạo
Các thông điệp được trao đổi trong SAML
- Trong SAML SSO, có 2 loại thông điệp chính cần quan tâm
- Thông điệp đi từ nhà cung cấp dịch vụ tới IDP được gọi là yêu cầu SAML (request)
- Thông điệp quay trở lại từ IDP tới nhà cung cấp dịch vụ được gọi là phản hồi SAML (response)
- Yêu cầu SAML thực ra không quá phức tạp. Chỉ cần gửi XML thông qua HTTP redirect là đủ
- Bao gồm ID trong thẻ
<AuthnRequest> để IDP có thể gửi lại <Response> gắn với yêu cầu ban đầu
- Dữ liệu được bọc trong thẻ
<Issuer> cũng được gửi tới IDP để cho biết bạn là ai
- Phản hồi SAML thì phức tạp hơn. Nó thường được gửi qua POST
- Về mặt khái niệm,
<Response> bao bọc một vài thẻ <Assertion>
<Assertion> bao bọc các claim về người dùng (họ là ai, họ đã xác thực với IDP như thế nào, v.v.)- Xử lý Assertion để quyết định có cho người dùng đăng nhập hay không
Lưu ý
- Ở đây đã lược bỏ rất nhiều chi tiết, đặc biệt là những nội dung quan trọng về bảo mật
- Nếu bạn không có hứng thú cá nhân với SAML hoặc không có lý do nghề nghiệp để nghiên cứu sâu, thì không nên tự triển khai đăng nhập dựa trên SAML. Đó là một sự lãng phí thời gian
- Nếu bạn muốn thiết lập SAML nhanh nhất có thể, chúng tôi cung cấp SSOReady mã nguồn mở đã trừu tượng hóa SAML. Nó sẽ giúp bạn tiết kiệm rất nhiều thời gian và công sức
Chưa có bình luận nào.