Trong ngữ cảnh của khung bảo mật, một số thuật ngữ thường xảy ra đối tượng , người dùng và hiệu trưởng , trong đó tôi không thể tìm thấy một định nghĩa rõ ràng và sự khác biệt giữa chúng.
Vì vậy, chính xác những điều khoản này có nghĩa là gì, và tại sao những sự phân biệt về chủ đề và hiệu trưởng cần thiết?
Câu trả lời:
Đây là thứ bậc theo cách mà chi, loài và cá thể được phân cấp.
Chủ đề / Đối tượng kế thừa từ các thuật ngữ tương tự như được sử dụng trong ngữ pháp. Trong một câu, chủ ngữ là diễn viên và đối tượng là vật được hành động. Theo nghĩa này, việc sử dụng đã có từ trước khi máy tính được phát minh. Trong bối cảnh bảo mật, một chủ đề là bất cứ điều gì có thể đưa ra yêu cầu. Như đã lưu ý ở trên, điều này không cần phải giới hạn trong bảo mật CNTT và do đó là một phân loại rất rộng. Điều thú vị là chủ đề ngụ ý đối tượng. Không có đối tượng thì không có chủ thể.
Hiệu trưởng là những gì đối tượng giải quyết. Khi bạn xuất trình thẻ tín dụng, bạn là chủ thể và số tài khoản là tiền gốc. Trong các bối cảnh khác, ID người dùng hoặc nhận dạng do nhà nước cấp là tiền gốc của bạn. Nhưng hiệu trưởng có thể được liên kết với nhiều loại chủ đề không phải là người. Khi các ứng dụng thực hiện các yêu cầu cho các chức năng ở cấp hệ thống, hiệu trưởng có thể là người ký của mô-đun mã thực thi đã ký nhưng ngay cả trong trường hợp đó, người dùng lái yêu cầu vẫn là chủ đề.
Người dùng cụ thể hơn chủ đề hoặc hiệu trưởng ở chỗ nó thường đề cập đến một toán tử tương tác. Đó là lý do tại sao chúng tôi có Giao diện người dùng đồ họa chứ không phải Giao diện hiệu trưởng đồ họa. Một người dùng là một ví dụ của chủ đề giải quyết cho một hiệu trưởng . Một người dùng có thể giải quyết với bất kỳ số lượng hiệu trưởng nào nhưng mọi hiệu trưởng dự kiến sẽ giải quyết cho một người dùng (giả sử mọi người tuân thủ yêu cầu không chia sẻ ID). Trong ví dụ trên, người ký mô-đun mã thực thi chắc chắn không phải là người dùng, nhưng nó là hiệu trưởng hợp lệ. Toán tử tương tác cố gắng để tải mô-đun là người dùng.
Như đã lưu ý trong các ý kiến, ngay cả các nguồn có thẩm quyền cũng không đồng ý với các điều khoản này. Tôi đã tìm kiếm NIST, Sans, IEEE, MITER và một số nguồn "gần như có thẩm quyền" như hướng dẫn kiểm tra bảo mật trong khi chuẩn bị phản hồi này. Không có nguồn nào mà tôi tìm thấy ít nhất là có thẩm quyền gần như bao gồm cả ba thuật ngữ và tất cả đều khác nhau đáng kể trong cách sử dụng. Đây là nhận định của tôi về cách các điều khoản nên được sử dụng nhưng từ một quan điểm thực tế, khi bạn đang nghiền ngẫm một hướng dẫn trong lúc nửa đêm, các định nghĩa có xu hướng bất cứ nhà cung cấp hoặc nhà văn nói họ đang có. Hy vọng rằng mặc dù các câu trả lời ở đây sẽ cung cấp đủ thông tin chi tiết để điều hướng vùng biển và phân tích bất kỳ tài liệu bảo mật nào bằng các điều khoản này.
John (human) SUBJECT > username_1 PRINCIPAL > password_1 USER John (human) SUBJECT > username_1 PRINCIPAL > password_2 USER John (human) SUBJECT > username_1 PRINCIPAL > smartcard_1 USER John (human) SUBJECT > username_1 PRINCIPAL > cellphone_1 USER
Hãy xem bản đồ khái niệm Xác thực của tôi :
Tôi nghĩ thuật ngữ này được lấy từ JAAS .
Khi một ứng dụng sử dụng xác thực JAAS để xác thực người dùng (hoặc thực thể khác như dịch vụ), kết quả là một Chủ đề được tạo. Mục đích của Chủ đề là đại diện cho người dùng được xác thực. Một Chủ đề bao gồm một tập hợp các Hiệu trưởng , trong đó mỗi Hiệu trưởng đại diện cho một danh tính cho người dùng đó. Ví dụ: Chủ thể có thể có tên Hiệu trưởng ("Susan Smith") và Hiệu trưởng Số An sinh Xã hội ("987-65-4321"), do đó phân biệt Chủ đề này với các Chủ thể khác.
Chủ thể là thực thể yêu cầu một dịch vụ. Nó có thể là một người dùng hoặc một quá trình. Có lẽ đó là lý do tại sao tên Chủ đề được chọn thay vì người dùng.
Khi một đối tượng cố gắng truy cập một dịch vụ, trước tiên đối tượng phải được xác thực. Xác thực thành công kết thúc bằng việc tải Nguyên tắc bảo mật cho Chủ đề đó. Ví dụ: trong hệ thống Kiểm soát truy cập dựa trên vai trò, người dùng được xác thực (đã đăng nhập) thường sẽ có hai nguyên tắc - userId và RoleId. Trong các hệ thống như vậy, các đặc quyền (tức là ai có thể truy cập cái gì) được chỉ định cho cả vai trò và cho người dùng. Trong khi ủy quyền (nghĩa là kiểm tra xem dịch vụ được yêu cầu có được phép hay không), hệ thống bảo mật sẽ kiểm tra khả năng truy cập đối với cả hai hiệu trưởng.
Do đó, từ góc độ ủy quyền, hiệu trưởng là các thực thể thực tế cho phép truy cập được phép hoặc không được phép. Chủ đề chỉ là một người dùng / chủ đề / quá trình chứa một số hiệu trưởng.
Như T.Rob đã giải thích, Chủ đề là bất kỳ thực thể nào yêu cầu quyền truy cập vào một đối tượng. Bắt đầu từ thời điểm đó tôi đã tìm thấy một nhận xét về javax.security.auth.Subject mã mà tôi đã thấy RẤT hữu ích và dễ hiểu:
"Chủ thể có thể có nhiều danh tính. Mỗi danh tính được thể hiện dưới dạng Hiệu trưởng trong Chủ đề. Hiệu trưởng chỉ cần liên kết tên với Chủ thể. Ví dụ: Chủ thể tình cờ là một người, Alice, có thể có hai Hiệu trưởng: một liên kết" Alice Bar ", tên trong giấy phép lái xe của cô, với Chủ đề và một tên khác liên kết," 999-99-9999 ", số trên thẻ nhận dạng học sinh của cô, cho Chủ đề. Cả hai Hiệu trưởng đều đề cập đến cùng một Chủ đề mặc dù mỗi có một tên khác. "
Hy vọng nó giúp.
Đây là liên kết để giải thích bên dưới từ Tài liệu Oracle JAVA SE.
Đối tượng, Hiệu trưởng, Xác thực và Thông tin xác thực Để ủy quyền truy cập vào tài nguyên, trước tiên, các ứng dụng cần xác thực nguồn của yêu cầu. Khung JAAS xác định chủ đề hạn để thể hiện nguồn của yêu cầu. Một chủ đề có thể là bất kỳ thực thể, chẳng hạn như một người hoặc dịch vụ. Một chủ đề được đại diện bởi javax.security.auth.Subject lớp .
Xác thực đại diện cho quá trình xác minh danh tính của một đối tượng và phải được thực hiện theo cách an toàn; nếu không, thủ phạm có thể mạo danh người khác để có quyền truy cập vào hệ thống. Xác thực thường liên quan đến đối tượng chứng minh một số dạng bằng chứng để chứng minh danh tính của mình. Bằng chứng đó có thể chỉ là thông tin mà chủ thể có thể biết hoặc có (như mật khẩu hoặc dấu vân tay) hoặc có thể chỉ là thông tin mà chủ thể có thể tạo ra (chẳng hạn như dữ liệu đã ký bằng khóa riêng).
Sau khi được xác thực, một Chủ đề được điền với các danh tính liên quan hoặc Hiệu trưởng (thuộc loại java.security.Principal ). Một môn học có thể có nhiều hiệu trưởng. Ví dụ: một người có thể có tên Hiệu trưởng ("John Doe") và Hiệu trưởng SSN ("123-45-6789"), để phân biệt với các Đối tượng khác.
Ngoài các Hiệu trưởng được liên kết, Chủ thể có thể sở hữu các thuộc tính liên quan đến bảo mật, được gọi là thông tin đăng nhập . Thông tin đăng nhập có thể chứa thông tin được sử dụng để xác thực chủ đề cho các dịch vụ mới. Thông tin đăng nhập như vậy bao gồm mật khẩu, vé Kerberos và chứng chỉ khóa công khai. Thông tin xác thực cũng có thể chứa dữ liệu cho phép chủ thể thực hiện các hoạt động nhất định. Ví dụ, khóa mật mã đại diện cho thông tin đăng nhập cho phép đối tượng ký hoặc mã hóa dữ liệu. Các lớp chứng chỉ công khai và riêng tư không phải là một phần của API J2SE cốt lõi. Bất kỳ lớp nào, do đó, có thể đại diện cho một thông tin.
theo rahulmohan ， tôi nghĩ, trước khi Xác thực là máy bay phụ, sau khi Xác thực là dự đoán, trong trường hợp khác, một máy bay phụ có thể có nhiều dự đoán