Xác nhận SAML với tên người dùng/mật khẩu - thông báo thực sự trông như thế nào?

Question

Tôi cần tạo một số xác nhận SAML 2.0 và tôi đang gặp khó khăn khi tìm thấy XML thực sự trông như thế nào. Hầu hết tài liệu dường như là về việc sử dụng các công cụ cụ thể, không phải về các thông báo. Tôi đã có các lược đồ, với rất nhiều khả năng, nhưng tôi không thể tìm thấy một ví dụ về những thông điệp có liên quan thực sự trông như thế nào trong thực tế.

Quy tắc nghiệp vụ cho biết: để tạo danh tính được chia sẻ, người dùng sẽ thông báo cho hệ thống Tên người dùng và mật khẩu của họ trên hệ thống B. Hệ thống A cần truyền đạt thông tin này (cùng với một số nhân khẩu học) tới hệ thống B. thông tin và chuyển lại mã định danh duy nhất mà sau đó có thể được sử dụng để chỉ người dùng này.

Ai đó có thể cho tôi ví dụ về xác nhận SAML 2.0 sẽ trông như thế nào để mang thông tin này?

FWIW, tôi đang sử dụng C# và cần chuyển XML theo những cách ngăn cản sử dụng công cụ của bên thứ ba.

Answer 1

Tôi không chắc chắn trường hợp sử dụng của bạn khá giống với SAML 2.0.

Những gì bạn mô tả như quy tắc kinh doanh của bạn thực sự trông giống như một trường hợp sử dụng cho việc cấp phép danh tính, chứ không phải quản lý truy cập.

Trường hợp sử dụng SAML 2.0 tiêu chuẩn tập trung vào một bên khẳng định nhận dạng (nhà cung cấp nhận dạng) và bên kia (hoặc các bên) dựa vào các xác nhận đó (nhà cung cấp dịch vụ). Các xác nhận mang những gì được gọi là một định danh tên, việc sử dụng nó được thỏa thuận trước thời hạn giữa nhà cung cấp nhận dạng và nhà cung cấp dịch vụ.

Các số nhận dạng tên này có thể là bất kỳ thứ gì, nhưng chúng được chia thành hai loại: tạm thời và liên tục. Định danh tên tạm thời chỉ hữu ích trong ngữ cảnh của phiên hiện tại (và về cơ bản chỉ nói, "Tôi biết người này là ai") và có xu hướng được sử dụng để bảo vệ danh tính của hiệu trưởng trong khi cho phép truy cập đặc quyền của một số loại. Một định danh liên tục có thể mờ đục (theo cách tương tự như cách OpenID được sử dụng để truy cập SO), trong đó bên khẳng định có thể liên tục xác minh danh tính của nguyên tắc mà không tiết lộ danh tính của chúng trong khi duy trì mã định danh động nhưng ổn định giữa khẳng định và dựa vào các bên hoặc quan trọng hơn, chẳng hạn như một Active Directory UPN (có thể được đồng thuận trước thời hạn).

Khi nói đến mật khẩu, như bạn đề cập trong câu hỏi của bạn, nhà cung cấp dịch vụ (dựa vào bên) không bao giờ thấy mật khẩu người dùng. Nhà cung cấp dịch vụ đưa người dùng đến nhà cung cấp nhận dạng với yêu cầu xác thực. Nhà cung cấp nhận dạng gửi người dùng quay trở lại nhà cung cấp dịch vụ với một phản hồi, trong trường hợp xác thực thành công chứa một xác nhận về danh tính của người dùng trong ngữ cảnh của mối quan hệ giữa nhà cung cấp nhận dạng và nhà cung cấp dịch vụ.

Trong ngữ cảnh câu hỏi của bạn, điều quan trọng là SAML 2.0 không cung cấp cách tạo tài khoản người dùng "ứng dụng" cục bộ hoặc liên kết tài khoản người dùng cục bộ với danh tính được liên kết. Đây không phải là vấn đề mà SAML 2.0 cố gắng giải quyết.

Bây giờ, hãy quay lại quy tắc kinh doanh của bạn ...

Có vẻ đối với tôi giống như những gì bạn đang cố gắng làm là một trong hai tài khoản liên kết hoặc đăng ký - Tôi sẽ tiếp cận nó như thế này:

• lần User ứng dụng, nhấp vào một nút để sử dụng danh từ nhà cung cấp danh tính
• Ứng dụng tạo yêu cầu xác thực và hướng người dùng đến nhà cung cấp nhận dạng, thực hiện yêu cầu xác thực đó
• Nhà cung cấp danh tính ghi nhật ký người dùng hoặc sử dụng lại phiên nhận dạng hiện tại nếu người dùng có. IdP tạo ra một thông báo phản hồi có chứa một xác nhận về người dùng. Trong trường hợp của bạn, xác nhận này nên ở mức tối thiểu mang theo một định danh tên liên tục. Nhà cung cấp nhận dạng hướng người dùng quay trở lại ứng dụng, mang theo thông báo phản hồi.
• Ứng dụng xử lý thông báo phản hồi. Nếu một mục nhập ánh xạ tồn tại đối với định danh liên tục được truyền thì người dùng được nhận ra từ ánh xạ đó và đăng nhập với tư cách là người dùng ứng dụng cục bộ đó. Nếu không có mục nhập bản đồ nào tồn tại, người dùng có thể được yêu cầu đăng nhập cục bộ và đăng nhập cục bộ thành công mục nhập bản đồ có thể được tạo hoặc tài khoản người dùng có thể được tạo tự động và người dùng có thể được yêu cầu nhập thông tin bổ sung (tên, địa chỉ email , vv) Trường hợp sử dụng "công ty" sẽ không được phép liên kết hoặc tạo tài khoản tự động và bản đồ phải tồn tại trước thời hạn.

Đối với các nội dung của các tin nhắn ...

Các OASIS Security Services Technical Committee có một tập tin tải về zip có sẵn với tài liệu phong phú của các bộ phận của lược đồ XML, bao gồm các ví dụ. Nó cũng đáng đọc đọc các giao thức và tài liệu hồ sơ, vì chúng mô tả dòng chảy của thông điệp giữa các bên liên quan đến cuộc trò chuyện nhận dạng.

Có một số lượng lớn các bản trình bày nổi xung quanh mà tôi thấy rất hữu ích. Cụ thể, SAML v2.0 Basics bởi Eve Maler đã giúp tôi bắt đầu nhận ra những vấn đề mà SAML v2.0 đang cố gắng giải quyết. Bản trình bày này bao gồm các ví dụ về xác nhận đó. Có bản trình bày được cập nhật và liên kết đến các tài nguyên bổ sung trên saml.xml.org.

Tôi không chắc chắn nếu bất kỳ điều này sẽ giúp mặc dù, vì trường hợp sử dụng của bạn dường như không phải là những gì SAML 2.0 đang cố gắng thực hiện. Bạn có thể thêm thuộc tính và tiện ích mở rộng khi cần để yêu cầu và phản hồi, nhưng tôi không thể thấy nhiều nhà cung cấp nhận dạng làm bất kỳ điều gì với các thuộc tính và phản hồi đó.